ईमेल हेडर एनालाइज़र

ब्राउज़र में चलता है नया वेब यूटिलिटीज़

मेल का हेडर-ब्लॉक पेस्ट करें (Gmail में "Show original", Outlook में "View message source") और एनालाइज़र उसे पूरी तरह आपके ब्राउज़र में पढ़ता है: हर Received हॉप उसी क्रम में जिसमें मेल गुज़रा, हॉप के बीच की देरी, SPF, DKIM और DMARC के फ़ैसले और उन्हें किस सर्वर ने दर्ज किया, From डोमेन envelope और सिग्नेचर से aligned है या नहीं, मेल कहाँ से शुरू हुआ इसके संभावित पते, और स्पैम-फ़िल्टर के फ़ैसले। हर finding बताती है कि उसका मतलब क्या है और हेडर पर कितना भरोसा किया जा सकता है, क्योंकि आपके अपने मेल सर्वर की लाइनों के नीचे की हर लाइन भेजने वाला ख़ुद लिख सकता है।

गोपनीयता: यह टूल पूरी तरह आपके ब्राउज़र में चलता है। आपका इनपुट कभी आपके डिवाइस से बाहर नहीं जाता।

किसी ईमेल के हेडर उसके कहाँ से आने के बारे में क्या दर्ज करते हैं?

मेल आगे बढ़ाने वाला हर सर्वर सबसे ऊपर एक Received लाइन जोड़ता है, इसलिए रास्ता सबसे नए से पढ़ा जाता है (RFC 5321), और आपका अपना रिसीविंग सर्वर Authentication-Results (RFC 8601) में दर्ज करता है कि SPF, DKIM और DMARC पास हुए या नहीं; DMARC तभी पास होता है जब From पते से aligned डोमेन के लिए SPF या DKIM पास हो (RFC 7489)। आपके सर्वर की लाइनों के नीचे का हर हेडर भेजने वाला लिख सकता है, इसलिए नतीजा तभी मायने रखता है जब उसका authserv-id आपका रिसीविंग सिस्टम हो, और pass भी सिर्फ़ यह बताता है कि किस डोमेन ने मेल की ज़िम्मेदारी ली, यह नहीं कि उसमें किया गया अनुरोध सच्चा है।

सुरक्षा नोट: हर जाँच पास करने वाला मेल भी मिलते-जुलते डोमेन से किया गया धोखा हो सकता है। भुगतान बदलने और लॉग-इन जानकारी माँगने वाले अनुरोधों की पुष्टि किसी ऐसे माध्यम से करें जिस पर आप पहले से भरोसा करते हैं, मेल के reply पते से कभी नहीं।

ईमेल हेडर एनालाइज़र कैसे इस्तेमाल करें

  1. मेल को अपने मेल क्लाइंट में खोलकर उसका source दिखाएँ: Gmail में "Show original", Outlook में File फिर Properties, Apple Mail में View फिर Message फिर All Headers।
  2. हेडर की पहली लाइन से पहली ख़ाली लाइन तक सब कुछ कॉपी करके फ़ील्ड में पेस्ट करें।
  3. "हेडर जाँचें" दबाएँ और "निष्कर्ष" से शुरू करें: उच्च और मध्यम गंभीरता वाले आइटम पर ही कार्रवाई की ज़रूरत होती है।
  4. Authentication नतीजे और भेजने वाले की पहचान व alignment पढ़कर देखें कि From पते के पीछे कोई सफल और aligned जाँच है या नहीं, फिर Received हॉप में मेल का रास्ता देखें।

ईमेल हेडर एनालाइज़र की खूबियाँ

  • पूरा हेडर-ब्लॉक आपके ब्राउज़र में पढ़ता है: कई लाइनों में मुड़े (folded) हेडर जोड़ता है, encoded नाम और subject डिकोड करता है, और ग़लती से पेस्ट हुई मेल-बॉडी छोड़ देता है
  • हर Received हॉप सबसे पुराने से क्रम में दिखाता है — भेजने वाला होस्ट, उसका पता, पाने वाला सर्वर, प्रोटोकॉल, TLS, UTC में समय और पिछले हॉप से देरी — साथ में कुल transit समय
  • SPF, DKIM और DMARC के फ़ैसले दर्ज नतीजे के ठीक शब्द (softfail, temperror …), उसे दर्ज करने वाले सर्वर और जिस हेडर से वह लिया गया, उसके साथ दिखाता है
  • DMARC जैसा alignment जाँचता है: envelope (Return-Path) डोमेन और DKIM साइनिंग डोमेन From डोमेन से strict या relaxed तरीके से मेल खाते हैं या नहीं
  • हर चेतावनी को गंभीरता के साथ पकड़ता है: दूसरे डोमेन का Reply-To, दूसरा पता दिखाने वाला display name, दोहराए गए From या Subject हेडर, छिपे अक्षर, reverse DNS का न होना, urgent के फ़्लैग और bulk-mailing स्क्रिप्ट
  • मेल के मूल पते के हर उम्मीदवार (X-Originating-IP, X-Sender-IP, सार्वजनिक पते वाला सबसे पुराना Received हॉप) की सूची देता है और उनके मेल न खाने पर चेताता है
  • SpamAssassin, Rspamd, Microsoft (SCL), Proofpoint, Barracuda और Amazon SES के हेडर से स्पैम-फ़िल्टर के फ़ैसले पढ़ता है

इनपुट और आउटपुट

इनपुट

  • मेल के हेडर — एक मेल का पूरा हेडर-ब्लॉक, जैसा मेल क्लाइंट दिखाता है, 2 MB तक; ख़ाली लाइन के बाद पेस्ट हुई बॉडी छोड़ दी जाती है।
  • और कुछ नहीं: न पता, न डोमेन, न कोई सेटिंग चाहिए, और कुछ भी fetch नहीं होता।

आउटपुट

  • सारांश और निष्कर्ष — तीनों फ़ैसले, हॉप की गिनती, transit समय और हर निष्कर्ष उसकी गंभीरता व मतलब के साथ।
  • Authentication नतीजे और भेजने वाले की पहचान व alignment — SPF, DKIM और DMARC का दर्ज नतीजा व उसे लिखने वाला सर्वर, From, envelope और साइनिंग डोमेन, और वे aligned हैं या नहीं।
  • Received हॉप, मूल पते के उम्मीदवार और मेल का ब्योरा — सबसे पुराने से रास्ता, समय और देरी के साथ, मेल कहाँ से शुरू हुआ हो सकता है वे पते, और From, To, Subject, Date, Message-ID व Return-Path जैसे लिखे थे।
  • DKIM सिग्नेचर, स्पैम फ़िल्टर, alignment नोट्स और "यह नतीजा कैसे पढ़ें" — हर सिग्नेचर का डोमेन, selector और एल्गोरिद्म, फ़िल्टर के फ़ैसले, alignment कैसे तय हुआ, और विश्लेषण क्या साबित नहीं कर सकता।

ईमेल हेडर एनालाइज़र का उदाहरण

ऐसा मेल जो किसी दूसरे डोमेन के लिए SPF और DKIM पास करता है पर DMARC में फ़ेल होता है

इनपुट:

"From: Example Accounts Payable <accounts@example.com>" और "Reply-To: ap-desk@payments-update.example" वाले मेल के हेडर, जो mail.billing-portal.example से भेजा गया और mx.google.com ने पाया (टूल का Load example)।

आउटपुट:

सारांश: SPF पास · DKIM पास · DMARC पास नहीं हुआ · Received हॉप 3 · Transit समय 00:00:10 · उच्च गंभीरता के निष्कर्ष 1 · मध्यम गंभीरता के निष्कर्ष 1
निष्कर्ष: उच्च — DMARC fail (विफल): रिसीविंग सर्वर ने दर्ज किया कि From पते के पीछे न aligned SPF pass है, न aligned DKIM pass · मध्यम — जवाब किसी दूसरे पते पर जाते हैं · निम्न — भेजने वाले होस्ट का मेल खाता reverse DNS नहीं · निम्न — Urgent चिह्नित · निम्न — देखने लायक़ सेंडिंग सॉफ़्टवेयर
Authentication नतीजे: SPF pass, DKIM pass, DMARC fail — तीनों सबसे नए Authentication-Results में mx.google.com ने दर्ज किए
भेजने वाले की पहचान और alignment: From डोमेन example.com · Envelope (Return-Path) डोमेन billing-portal.example · SPF, From से aligned: नहीं · DKIM, From से aligned: नहीं
Received हॉप: 1 WIN-7Q2J4KD 203.0.113.77 → mail.billing-portal.example 09:13:59 · 2 → mx.google.com +00:00:09 · 3 +00:00:01

ईमेल हेडर एनालाइज़र के नतीजे कैसे पढ़ें

DMARC "पास नहीं हुआ" का मतलब है कि रिसीविंग सर्वर ने दर्ज किया कि From पते के पीछे न aligned SPF pass है, न aligned DKIM pass। जाली मेल ऐसा दिखता है, पर forward हुए या मेलिंग लिस्ट से गुज़रे मेल भी ऐसे ही दिखते हैं; अगर मेल पैसे, लॉग-इन जानकारी या बैंक खाता बदलने की माँग करे, तो कुछ करने से पहले किसी दूसरे माध्यम से पुष्टि करें।

SPF और DKIM "पास" पर "From से aligned: नहीं" का मतलब है कि जाँच ने किसी दूसरे डोमेन की पुष्टि की — किसी सेंडिंग सर्विस या मिलते-जुलते नाम की — न कि उस पते की जो पढ़ने वाला देखता है। ऐसी सर्विस से भेजा मेल जो From डोमेन के नाम से साइन नहीं करती, ऐसा ही दिखता है, और मिलते-जुलते डोमेन से आया मेल भी।

"दर्ज नहीं" का मतलब है कि किसी भरोसेमंद रिसीवर ने उस जाँच का नतीजा नहीं लिखा; यह fail नहीं है। निष्कर्षों में कोई foreign Authentication-Results हो तो वही बताता है कि कोई नतीजा क्यों अलग रखा गया।

उच्च गंभीरता के निष्कर्ष मेल पर भरोसा न करने की वजहें हैं (DMARC fail, display name में छिपा पता, पते के अंदर छिपे अक्षर); मध्यम वाले दोबारा देखने लायक़ हैं; निम्न और जानकारी वाले मेल पर आरोप लगाने से ज़्यादा उसका वर्णन करती हैं।

दो हॉप के बीच मिनटों से घंटों की देरी अक्सर कतार या greylisting होती है, छेड़छाड़ नहीं; नेगेटिव देरी का मतलब है कि दो सर्वरों की घड़ियाँ अलग हैं या कोई Received लाइन भेजने वाले ने लिखी।

ईमेल हेडर एनालाइज़र कब इस्तेमाल करें

  • भुगतान बदलने या पासवर्ड रीसेट करने को कहने वाले मेल के बारे में रिसीविंग सर्वर ने क्या दर्ज किया — उसके From डोमेन के पीछे कोई सफल और aligned जाँच है या नहीं — यह उस पर कार्रवाई से पहले देखना।
  • किसी सहकर्मी या ग्राहक को समझाना कि उनका मेल स्पैम में क्यों गया: DKIM नहीं, envelope डोमेन aligned नहीं, reverse DNS नहीं।
  • धीमा मेल कहाँ अटका यह जानना: लंबी देरी वाला हॉप उसे रोकने वाले सर्वर का नाम बताता है।
  • abuse रिपोर्ट के तथ्य जुटाना: मूल पते के उम्मीदवार, सेंडिंग सर्विस और रिसीविंग सर्वर की अपनी लाइन।

समस्या निवारण

  • "कोई हेडर लाइन नहीं मिली": पेस्ट मेल के टेक्स्ट से शुरू होता है। मूल source कॉपी करें, जो Received: या Delivered-To: जैसी लाइनों से शुरू होता है।
  • हर फ़ैसला "दर्ज नहीं" है: हेडर भेजने वाले के Sent फ़ोल्डर से कॉपी हुए, या रिसीविंग सर्वर Authentication-Results नहीं लिखता। पाने वाले के मेलबॉक्स वाली कॉपी जाँचें।
  • कोई नतीजा "रिसीविंग सर्वर का नहीं" बताया गया: आपके मेलबॉक्स के आगे का कोई गेटवे दूसरे नाम से नतीजे लिखता है। गेटवे आपका है तो उसके नतीजे भरोसेमंद हैं, वरना उन्हें भेजने वाले का दावा मानें।
  • लाइनें "ऊपर वाले हेडर में जोड़ी गईं": कॉपी में folded हेडर का indent खो गया। फ़ॉर्मैट किए गए व्यू की जगह raw source व्यू से कॉपी करें।

ईमेल हेडर एनालाइज़र के बारे में अक्सर पूछे जाने वाले सवाल

किसी मेल के पूरे हेडर कहाँ मिलते हैं?

Gmail में मेल खोलें, तीन-बिंदु वाले मेन्यू में Show original चुनें। Outlook डेस्कटॉप में मेल खोलकर File, फिर Properties चुनें और Internet headers बॉक्स कॉपी करें; वेब वाले Outlook में More actions, फिर View, फिर View message details। Apple Mail में View, Message, All Headers और Thunderbird में View, Message Source। पहली लाइन से पहली ख़ाली लाइन तक सब कॉपी करें: अधूरा पेस्ट हॉप और नतीजे छिपा देता है।

फ़ैसला कौन-सा Authentication-Results हेडर तय करता है?

आपके अपने रिसीविंग सर्वर का लिखा सबसे नया हेडर — यानी सबसे ऊपर का वह हेडर जिसका authserv-id Received ट्रेस के रिसीविंग हिस्से के किसी होस्ट से मेल खाता है। किसी और नाम से लिखा हेडर "रिसीविंग सर्वर का नहीं" दिखाया जाता है और इस्तेमाल नहीं होता। आपके सर्वर का ठीक नाम कॉपी करने वाला जाली हेडर असली से अलग नहीं पहचाना जा सकता; बचाव सिर्फ़ यह है कि रिसीवर अपने नाम का दावा करने वाले आने वाले हेडर हटा दें (RFC 8601 §5), इसलिए जाँच लें कि आपका मेल सिस्टम ऐसा करता है।

कुछ समय "जैसे लिखे थे" क्यों दिखते हैं, बदले क्यों नहीं जाते?

जिस तारीख़ में टाइम ज़ोन नहीं है, या IST या BST जैसा संक्षेप है जिसका मतलब अलग-अलग जगह अलग offset होता है, उसे समय-रेखा पर नहीं रखा जा सकता। एनालाइज़र ऐसी तारीख़ ठीक वैसी ही दिखाता है, उसे देरी और transit के हिसाब से बाहर रखता है और अंदाज़ा लगाने के बजाय यह साफ़ बताता है।

क्या originating IP भेजने वाले का कंप्यूटर होता है?

ज़रूरी नहीं। X-Originating-IP भेजने वाले की वेबमेल या मेल सर्विस लिखती है, X-Sender-IP Microsoft के फ़िल्टर, और सार्वजनिक पते वाली सबसे पुरानी Received लाइन भेजने वाला ख़ुद भी लिख सकता है। इसलिए हर उम्मीदवार उसके स्रोत के साथ दिखाया जाता है; मेल न खाएँ तो उस लाइन पर भरोसा करें जो आपके सर्वर ने मेल सौंपने वाले होस्ट के बारे में लिखी।

क्या "DKIM pass" साबित करता है कि मेल किसने भेजा?

यह साबित करता है कि साइनिंग डोमेन (d=) ने साइन किए गए हेडर और बॉडी की, जैसे वे पहुँचे, ज़िम्मेदारी ली। From पते का समर्थन यह तभी करता है जब वह डोमेन From डोमेन से aligned हो — DMARC ठीक यही जाँचता है; किसी सेंडिंग सर्विस के अपने डोमेन का pass From पते के बारे में कुछ नहीं कहता।

क्या मेरे हेडर अपलोड होते हैं या कहीं खोजे जाते हैं?

नहीं। विश्लेषण आपके ब्राउज़र में होता है, कुछ भेजा या सहेजा नहीं जाता। कोई नेटवर्क रिक्वेस्ट न होने से DKIM सिग्नेचर प्रकाशित key से जाँचे नहीं जाते और पते ब्लैकलिस्ट में नहीं खोजे जाते; यह काम IP ब्लैकलिस्ट चेकर और DKIM रिकॉर्ड चेकर माँगने पर करते हैं।

तकनीकी नोट्स

हेडर-ब्लॉक RFC 5322 का मैसेज-हेडर है: लंबे फ़ील्ड उन लाइन-ब्रेक पर जोड़े जाते हैं जो भेजने वाले ने डाले, गैर-ASCII नाम और subject RFC 2047 के encoded words से डिकोड होते हैं, और From, Subject, Message-ID जैसे फ़ील्ड एक ही बार होने चाहिए। मेल आगे बढ़ाने वाला हर सर्वर सबसे ऊपर एक Received फ़ील्ड जोड़ता है (RFC 5321 §4.4), इसलिए ब्लॉक सबसे नए से शुरू होता है; टूल उसे उलटकर यात्रा क्रम से दिखाता है।

रिसीवर अपनी जाँच Authentication-Results (RFC 8601) में दर्ज करते हैं: पहला टोकन authserv-id है जो लिखने वाले सिस्टम का नाम बताता है, फिर spf=pass smtp.mailfrom=…, dkim=fail header.d=… और dmarc=fail header.from=… जैसे नतीजे। रास्ते में कोई भी ऐसा हेडर लिख सकता है, इसलिए सिर्फ़ रिसीवर के अपने हेडर मायने रखते हैं (RFC 8601 §5): टूल हर फ़ैसला उस सबसे नए Authentication-Results से लेता है जिसका authserv-id Received ट्रेस के रिसीविंग हिस्से के किसी होस्ट से मेल खाता है, SPF के लिए सबसे नए Received-SPF (RFC 7208 §9.1) पर लौटता है, और बाक़ी हर हेडर को foreign बताता है।

DMARC (RFC 7489 §3.1) तभी पास होता है जब From डोमेन से aligned किसी envelope डोमेन के लिए SPF पास हो, या aligned साइनिंग डोमेन के लिए DKIM पास हो — relaxed मोड में वही organizational डोमेन, strict मोड में बिल्कुल वही डोमेन। Organizational डोमेन टूल में शामिल Public Suffix List से निकाला जाता है। ARC सेट (RFC 8617) का सार दिखाया जाता है पर वे कोई फ़ैसला तय नहीं करते: वे बताते हैं कि किसी बीच के सर्वर ने क्या देखा।

देरी सिर्फ़ उन हॉप के बीच गिनी जाती है जिनकी तारीख़ में इस्तेमाल लायक़ टाइम ज़ोन हो; बिना ज़ोन या अस्पष्ट संक्षेप (IST, BST, AST) वाली तारीख़ जैसी लिखी थी वैसी रखकर छोड़ दी जाती है, और ऐसे हॉप के पार नापी गई देरी बताती है कि वह किस हॉप से गिनी गई।

सीमाएँ और कार्यप्रणाली

इंटरनेट पर कुछ भी सत्यापित नहीं होता: DKIM सिग्नेचर प्रकाशित key से नहीं जाँचे जाते, पते ब्लैकलिस्ट में नहीं खोजे जाते और SPF दोबारा नहीं आँका जाता — टूल सिर्फ़ वही बताता है जो रिसीविंग सर्वरों ने दर्ज किया।

आपके मेल सर्वर की लाइनों के नीचे के हेडर भेजने वाला लिख सकता है। आपके रिसीविंग सर्वर का ठीक authserv-id कॉपी करने वाला जाली Authentication-Results असली से अलग नहीं पहचाना जा सकता; इससे बचाव सिर्फ़ यही है कि रिसीवर पहुँचते ही ऐसे हेडर हटा दे (RFC 8601 §5)।

मूल पता सिर्फ़ उम्मीदवार है: X-Originating-IP और सबसे पुरानी Received लाइनें भेजने वाली तरफ़ लिख सकती है, और वेबमेल या VPN इस्तेमाल करने वालों का पता उनके प्रोवाइडर का दिखता है।

समय उतने ही सही हैं जितनी हर सर्वर की घड़ी, और इस्तेमाल लायक़ टाइम ज़ोन के बिना वाली तारीख़ें बदली नहीं जातीं।

सुरक्षा और गोपनीयता

हेडर आपके ब्राउज़र में जाँचे जाते हैं, कभी भेजे, खोजे या सहेजे नहीं जाते, इसलिए उनमें मौजूद लोगों के नाम और पते आपके डिवाइस पर ही रहते हैं।

संदर्भ

  • RFC 8601: Message Header Field for Indicating Message Authentication StatusIETF · 2019Authentication-Results हेडर: authserv-id, हर तरीके का नतीजा, और रिसीवर को अपने नाम का दावा करने वाले हेडर क्यों हटाने चाहिए।
  • RFC 5322: Internet Message FormatIETF · 2008ई-मेल मैसेज और पते (local-part@domain) का सिंटैक्स जिसके विरुद्ध वैलिडेटर परखे जाते हैं।
  • RFC 5321: Simple Mail Transfer ProtocolIETF · 2008SMTP प्रोटोकॉल, जिसमें §5.1 भी है: भेजने वाला सर्वर MX रिकॉर्ड को preference के क्रम में कैसे लगाता है, बराबर वालों को रैंडम करता है और MX न होने पर डोमेन के अपने एड्रेस पर लौटता है।