ईमेल हेडर्स अनलॉक करें: स्पैम, फ़िशिंग पहचानें, और अपने इनबॉक्स की रक्षा करें

क्या आपको कभी किसी ऐसे ईमेल पते से स्पैम या फ़िशिंग संदेश मिला है जिसे आप नहीं पहचानते? शायद किसी ने आपको मुफ्त यात्रा की पेशकश की, व्यक्तिगत तस्वीरों के बदले बिटकॉइन भेजने के लिए कहा, या सिर्फ एक अवांछित मार्केटिंग ईमेल भेजा?

क्या आपने सोचा है कि वे ईमेल कहाँ से आए? किसी स्पैमर को अपना ईमेल पता स्पूफ करते देखा और सोचा कि उन्होंने यह कैसे किया?

ईमेल स्पूफिंग, या एक ईमेल को ऐसा दिखाना जैसे वह उस पते से आया हो जो उसने नहीं किया (उदाहरण के लिए एक ईमेल जो whitehouse.gov से आने वाला प्रतीत होता है, लेकिन वास्तव में एक स्कैमर से है) आश्चर्यजनक रूप से आसान है।

कोर ईमेल प्रोटोकॉल में प्रमाणीकरण के लिए कोई विधि नहीं है, जिसका अर्थ है कि 'from' पता मूल रूप से सिर्फ एक भरने वाला खाली स्थान है।

आमतौर पर जब आपको कोई ईमेल मिलता है, तो यह कुछ इस तरह दिखता है:

From: Name <name@gmail.com>
Date: Tuesday, July 16, 2019 at 10:02 AM
To: Me <Me@freecodecamp.com>

उसके नीचे विषय और संदेश होता है।

लेकिन आप कैसे जानते हैं कि वह ईमेल वास्तव में कहाँ से आया? क्या कोई अतिरिक्त डेटा है जिसका विश्लेषण किया जा सकता है?

हम जो खोज रहे हैं वह पूर्ण ईमेल हेडर्स हैं — जो आप ऊपर देखते हैं वह सिर्फ एक आंशिक हेडर है। यह डेटा हमें कुछ अतिरिक्त जानकारी देगा कि ईमेल कहाँ से आया और यह आपके इनबॉक्स तक कैसे पहुंचा।

यदि आप अपने स्वयं के ईमेल हेडर्स देखना चाहते हैं, तो यहां Outlook और Gmail पर उन्हें एक्सेस करने का तरीका बताया गया है। अधिकांश मेल प्रोग्राम इसी तरह काम करते हैं, और एक साधारण Google खोज आपको बताएगी कि वैकल्पिक मेल सेवाओं पर हेडर्स कैसे देखें।

इस लेख में हम वास्तविक हेडर्स के एक सेट को देखेंगे (हालांकि वे भारी रूप से रिडैक्टेड हैं — मैंने होस्टनाम, टाइमस्टैम्प, और IP पते बदल दिए हैं)।

हम हेडर्स को ऊपर से नीचे पढ़ेंगे, लेकिन ध्यान रखें कि प्रत्येक नया सर्वर ईमेल बॉडी के शीर्ष पर अपना हेडर जोड़ता है। इसका मतलब है कि हम अंतिम मैसेज ट्रांसफर एजेंट (MTA) से हेडर पढ़ेंगे और पहले MTA तक काम करेंगे जिसने संदेश स्वीकार किया।

आंतरिक ट्रांसफर

Received: from REDACTED.outlook.com (IPv6 Address) by REDACTED.outlook.com with HTTPS via REDACTED.OUTLOOK.COM; Fri, 25 Oct 2019 20:16:39 +0000

यह पहला हॉप एक HTTPS लाइन दिखाता है, जिसका अर्थ है कि सर्वर ने मानक SMTP के माध्यम से संदेश प्राप्त नहीं किया और इसके बजाय वेब एप्लिकेशन पर प्राप्त इनपुट से संदेश बनाया।

Received: from REDACTED.outlook.com (IPv6Address) by REDACTED.outlook.com (IPv6Address) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1358.20; Fri, 25 Oct 2019 20:16:38 +0000
Received: from REDACTED.outlook.com (IPv6Address) by REDACTED.outlook.office365.com (IPv6Address) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2385.20 via Frontend Transport; Fri, 25 Oct 2019 20:16:37 +0000
Authentication-Results: spf=softfail (sender IP is REDACTEDIP)smtp.mailfrom=gmail.com; privatedomain.com; dkim=pass (signature was verified)header.d=gmail.com;privatedomain.com; dmarc=pass action=noneheader.from=gmail.com;compauth=pass reason=100
Received-SPF: SoftFail (REDACTED.outlook.com: domain of transitioning gmail.com discourages use of IPAddress as permitted sender)

ये पहले दो हेडर ब्लॉक आंतरिक मेल ट्रांसफर हैं। आप बता सकते हैं कि ये Office365 सर्वरों (outlook.com) द्वारा प्राप्त किए गए थे, और आंतरिक रूप से सही प्राप्तकर्ता को रूट किए गए थे।

आप यह भी बता सकते हैं कि संदेश एन्क्रिप्टेड SMTP के माध्यम से भेजा जा रहा है। आप इसे जानते हैं क्योंकि हेडर "with Microsoft SMTP Server" सूचीबद्ध करता है और फिर TLS संस्करण निर्दिष्ट करता है जिसका वह उपयोग कर रहा है, साथ ही विशिष्ट सिफर।

तीसरा हेडर ब्लॉक एक स्थानीय मेल सर्वर से मेल फ़िल्टरिंग सेवा में संक्रमण को चिह्नित करता है। आप इसे जानते हैं क्योंकि यह "via Frontend Transport" गया था जो Microsoft-Exchange विशिष्ट प्रोटोकॉल है (और इसलिए यह सख्ती से SMTP नहीं था)।

यह ब्लॉक कुछ ईमेल जांच भी शामिल करता है। Outlook.com का हेडर यहां उनके SPF/DKIM/DMARC परिणामों का विवरण दे रहा है। एक SPF सॉफ्टफेल का अर्थ है कि यह IP पता gmail.com की ओर से ईमेल भेजने के लिए अधिकृत नहीं है।

"dkim=pass" का अर्थ है कि ईमेल अपने कथित प्रेषक से है और (सबसे अधिक संभावना) ट्रांजिट में बदला नहीं गया था।

DMARC नियमों का एक सेट है जो मेल सर्वर को बताता है कि SPF और DKIM परिणामों की व्याख्या कैसे करें। पास का अर्थ है कि ईमेल अपने गंतव्य तक जारी रहता है।

SPF, DKIM, और DMARC पर अधिक जानकारी के लिए, इस लेख को देखें।

आंतरिक/बाहरी संक्रमण

Received: from Redacted.localdomain.com (IP address) by redacted.outlook.com (IP address) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2305.15 via Frontend Transport; Fri, 25 Oct 2019 20:16:37 +0000
Received-SPF: None (Redacted.localdomain.com: no sender authenticity information available from domain of sender@gmail.com) identity=xxx; client-ip=IP address; receiver=Redacted.localdomain.com; envelope-from="sender@gmail.com"; x-sender="sender@gmail.com"; x-conformance=sidf_compatible
Received-SPF: Pass (Redacted.localdomain.com: domain of sender@gmail.com designates sending IP as permitted sender) identity=mailfrom; client-ip=IP address2; receiver=Redacted.localdomain.com; envelope-from="sender@gmail.com"; x-sender="sender@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"

यह Google का SPF रिकॉर्ड है - प्राप्त सर्वर को बता रहा है कि जो ईमेल कहता है कि वह gmail.com से आ रहा है, वह Google-अनुमोदित सर्वर से आ रहा है।

Received-SPF: None (redacted.localdomain.com: no sender authenticity information available from domain of postmaster@redatedgoogle.com) identity=helo; client-ip=IP address; receiver=Redacted.localdomain.com; envelope-from="sender@gmail.com"; x-sender="postmaster@.google.com"; x-conformance=sidf_compatible
Authentication-Results-Original: Redacted@localdomain.com; spf=None smtp.pra=sender@gmail.com; spf=Pass smtp.mailfrom=sender@gmail.com; spf=None smtp.helo=postmaster@redacted.google.com; dkim=pass (signature verified) header.i=@gmail.com; dmarc=pass (p=none dis=none) d=gmail.com
IronPort-SDR: IronPort-PHdr: =X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =X-IronPort-AV: ;d="scan"
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False

यह कुछ अतिरिक्त SPF/DKIM/DMARC जांचों के साथ-साथ IronPort स्कैन के परिणाम दिखाता है।

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

Received: from redacted.google.com ([IP Address]) by Redacted.localdomain.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; Fri, 25 Oct 2019 16:16:36 -0400
Received: by redacted.google.com with SMTP id for recipient@localdomain.com; Fri, 25 Oct 2019 13:16:35 -0700 (PDT)
X-Received: by IPv6:: with SMTP id; Fri, 25 Oct 2019 13:16:35 -0700 (PDT)
Return-Path: sender@gmail.com
Received: from senderssmacbook.fios-router.home (pool-.nycmny.fios.verizon.net. [IP address redacted]) by smtp.gmail.com with ESMTPSA id redacted IP (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 25 Oct 2019 13:16:34 -0700 (PDT)
Received: from senderssmacbook.fios-router.home (pool-.nycmny.fios.verizon.net. [IP address redacted]) by smtp.gmail.com with ESMTPSA id redacted IP (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 25 Oct 2019 13:16:34 -0700 (PDT)

यह खंड प्रेषक के प्रारंभिक डिवाइस के माध्यम से Gmail के रूटिंग सिस्टम और प्राप्तकर्ता के Outlook वातावरण तक ईमेल द्वारा लिए गए आंतरिक हॉप्स को दर्शाता है। इससे हम देख सकते हैं कि प्रारंभिक प्रेषक एक मैकबुक से था, होम राउटर का उपयोग कर रहा था, NYC में Verizon Fios के साथ।

यह प्रेषक से प्राप्तकर्ता तक ईमेल द्वारा लिए गए मार्ग को दिखाने वाले हॉप्स का अंत है। इसके बाद, आप ईमेल का बॉडी देखेंगे (और हेडर्स जो आप आमतौर पर देखते हैं जैसे "from:", "to:", आदि), शायद मीडिया प्रकार और ईमेल क्लाइंट के आधार पर कुछ फॉर्मेटिंग के साथ (उदाहरण के लिए MIME संस्करण, सामग्री प्रकार, सीमा, आदि)। इसमें कुछ उपयोगकर्ता-एजेंट जानकारी भी हो सकती है, जो संदेश भेजने वाले डिवाइस के प्रकार पर विवरण है।

इस मामले में हम पहले से ही जानते हैं कि भेजने वाला डिवाइस Apple के नामकरण परंपरा के कारण एक मैकबुक था, लेकिन इसमें CPU प्रकार, संस्करण, यहां तक कि डिवाइस पर इंस्टॉल किए गए ब्राउज़र और संस्करण पर विवरण भी हो सकते हैं।

कुछ मामलों में, लेकिन सभी में नहीं, इसमें भेजने वाले डिवाइस का IP पता भी हो सकता है (हालांकि कई प्रदाता उस जानकारी को सम्मन के बिना छिपा देंगे)।

ईमेल हेडर्स आपको क्या बता सकते हैं?

ईमेल हेडर्स यह पहचानने में मदद कर सकते हैं कि ईमेल कब उनके कथित प्रेषकों से नहीं भेजे जा रहे हैं। वे प्रेषक पर कुछ जानकारी प्रदान कर सकते हैं - हालांकि यह आमतौर पर वास्तविक प्रेषक की पहचान करने के लिए पर्याप्त नहीं है।

कानून प्रवर्तन अक्सर सही ISP से जानकारी सम्मन करने के लिए इस डेटा का उपयोग कर सकता है, लेकिन हम में से बाकी ज्यादातर इसका उपयोग जांच को सूचित करने में मदद के लिए कर सकते हैं, आमतौर पर फ़िशिंग में।

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

प्रत्येक सर्वर के मालिक से संपर्क किए बिना और व्यक्तिगत रूप से सत्यापित किए बिना कि आपके ईमेल में हेडर्स उनके SMTP लॉग से मेल खाते हैं, जो श्रमसाध्य और समय लेने वाला है, आप निश्चित नहीं होंगे कि हेडर्स सभी सटीक हैं।

DKIM, DMARC और SPF इस प्रक्रिया में मदद कर सकते हैं, लेकिन वे पूर्ण नहीं हैं, और उनके बिना, कोई सत्यापन नहीं है।

अपने हेडर्स का विश्लेषण नहीं करना चाहते? यह साइट आपके लिए यह करेगी।