सवाल मुझे भेजा गया ईमेल MAIL@MAIL.COM को संबोधित किया गया है। यह कैसे किया जाता है?


मुझे हाल ही में एक घोटाला ईमेल भेजा गया था, और गिगल्स के लिए मैंने इसे पढ़ने के लिए इसे खोल दिया। बहुत सादा, और इसमें ज्यादा प्रयास नहीं किया गया।

मैंने कुछ असाधारण देखा; यह ईमेल मुझे संबोधित नहीं किया गया था। सबसे पहले, मुझे एक सीसी, या बीसीसी पर संदेह था, लेकिन मेल पर मेरा पता कहीं भी नहीं है। मैंने नीचे एक तस्वीर प्रदान की है। यह कैसे किया जाता है?

enter image description here


103
2018-05-15 18:22


मूल


पूर्ण संदेश शीर्षलेख पोस्ट करें ... आपके पास ईमेल सर्वर पर एक माध्यमिक एसएमटीपी पता भी हो सकता है जिसे यह शायद भेजा गया था। ईमेल सर्वर व्यवस्थापक इस पर आपको सलाह देने में सक्षम होना चाहिए लेकिन संपादित करें आप इस संदेश के पूर्ण संदेश शीर्षलेख का उत्तर भी देते हैं और पोस्ट करते हैं। - Pimp Juice IT
आप शायद में थे ब्लाइंड कार्बन कॉपी ईमेल का क्षेत्र - Mokubai♦
आपको बीसीसी सूची नहीं दिखाई देगी, वह "बी" लिंड हिस्सा है। ;) - Ƭᴇcʜιᴇ007
@tuskiomi नहीं, आउटलुक में नहीं। जीमेल दिखाता है bcc: me, शायद अन्य भी साथ ही ... लेकिन यदि आप पूर्ण संदेश शीर्षलेख देखते हैं तो आपको वहां अपना ईमेल देखना चाहिए - wysiwyg
@ टुस्कीमी - नहीं, आप कभी भी बीसीसी में सूचीबद्ध किसी को भी नहीं देख पाएंगे, यहां तक ​​कि खुद भी नहीं। इसके अलावा, यदि यह स्पैम है, तो भी एक वास्तविक बीसीसी सूची नहीं हो सकती है; स्पैमवेयर प्राप्तकर्ता सूची को किसी भी तरह से प्रबंधित कर सकता है, और आखिरकार मायने रखता है कि मेल सर्वर के साथ स्पैमवेयर की बातचीत कैसा दिखती है - मेल की सामग्री क्या नहीं है। यदि आप इंटरनेट हेडर देखते हैं तो एकमात्र तरीका आपको अपना ईमेल पता दिखाई देगा। - Jeff Zeitlin


जवाब:


एक इंटरनेट ई-मेल संदेश में दो भाग होते हैं। हम उन्हें संदर्भित कर सकते हैं लिफ़ाफ़ा और यह पेलोड संदेश या केवल संदेश

लिफाफा में रूटिंग डेटा है: मुख्य रूप से, यह प्रेषक पता और एक या अधिक प्राप्तकर्ता पते है।

संदेश में संदेश सामग्री है: विषय पंक्ति, संदेश शरीर, अनुलग्नक, आदि। इसमें कुछ तकनीकी जानकारी भी होती है जैसे ट्रेस (Received:) हेडर, डीकेआईएम डेटा, और इसी तरह; साथ ही साथ दिखाया गया है प्रेषक और प्राप्तकर्ता के पते (जो आप देखते हैं From, To तथा Cc आपके मेल क्लाइंट में फ़ील्ड)।

यहां का क्रूक्स है: दोनों को सहमत नहीं होना चाहिए!

संदेश भेजने के तरीके को निर्धारित करने के लिए एक मेल सर्वर लिफाफा डेटा को देखेगा। दूसरी तरफ, कुछ अपवादों के साथ, संदेश को केवल डेटा के रूप में माना जाएगा। विशेष रूप से, एक अच्छी तरह से व्यवहार मेल सर्वर नहीं करता की ओर देखने के लिए To: तथा Cc: प्राप्तकर्ताओं की सूची निर्धारित करने के लिए संदेश के क्षेत्र स्वयं ही, और न ही यह देखता है From: प्रेषक के पते को निर्धारित करने के लिए क्षेत्र।

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

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

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

चूंकि प्राप्त ई-मेल क्लाइंट प्रदर्शित करता है कि से, टू और सीसी हेडर में क्या है, लिफाफा से पता डेटा नहीं, आप जो कुछ भी चाहते हैं उसे रखना संभव है और प्राप्त करने वाले ई-मेल क्लाइंट का कोई सहारा नहीं होगा लेकिन विश्वास करने के लिए कि यह उचित रूप से सटीक है। वैध मेल के लिए यह आमतौर पर पर्याप्त सटीक है; स्पैम के लिए, यह लगभग कभी नहीं है।

मूर्त, दुनिया में हमारे द्वारा निवास किए जाने वाले भौतिक वस्तुओं की दुनिया में,  लिफाफा प्रेषक तथा लिफाफा प्राप्तकर्ता अनुक्रम पते और प्राप्तकर्ता का पता क्रमशः, लिफाफे के बाहर लिखते हैं; और यह From: तथा To:/Cc: हेडर जो लिफाफे में रखे गए पत्र में क्रमशः आपके और प्राप्तकर्ता के पते के रूप में रखे गए हैं।


154
2018-05-15 18:56



मेरी इच्छा है कि लोगों ने यहां अधिक वास्तविक दुनिया के अनुरूप बनाये ताकि अन्य समझ सकें कि भौतिक समकक्ष क्या है। ईमेल का "प्रेषक" मेलमैन को लिफाफा देने वाले व्यक्ति की तरह है; "से" पता वह है जिसका उद्देश्य यह होना है। जैसे आप किसी और की तरफ इत्यादि भेज रहे सचिव हो सकते हैं। - Mehrdad
@ मेहरदाद संख्या; (एसएमटीपी) लिफाफा प्रेषक पता लिफाफे के बाहर वापसी पते की तरह है (जहां इसे भेजा जा सकता है, जहां इसे भेजा जा सकता है), जबकि पते में From हेडर वह है जो आप कागज़ के टुकड़े पर लिखते हैं जो आप चिपकते हैं के भीतर लिफाफा और मेलमैन को इसके बारे में भी पता नहीं है। - α CVn
मैं प्रेषक के बारे में सोच रहा था: हेडर जब मैंने लिखा था, और यह सिर्फ एक उदाहरण था। बस यह कहकर कि आपके उत्तर में ऐसा उदाहरण जोड़ना अच्छा लगेगा। - Mehrdad
यहां बोल्डिंग की मात्रा सच है सबसे अच्छा अनावश्यक। और यह है केवल मेरी राय। - JakeGould
@SupremeGrandRuler क्योंकि प्राप्त करने वाला जानकारी (संभावित प्रेषक या रिटर्न-पथ के विपरीत) ईमेल में निहित नहीं है। कल्पना करें कि पूर्ण प्राप्तकर्ता सूची शामिल थी, एमयूए को बीसीसी क्षेत्र से प्राप्त पते सहित (याद रखें: एसएमटीपी (लिफाफा प्रोटोकॉल) बीसीसी के बारे में नहीं जानता है, यह केवल प्राप्तकर्ताओं के बारे में जानता है) ... यह एक गोपनीयता समस्या होगी (और एक अंतरिक्ष की भारी अपशिष्ट) न केवल बड़ी मेलिंग सूचियों पर (बीसीसी के समान सिद्धांत द्वारा संचालित)। - Jonas Schäfer


टीएल; नीचे डॉ।

एसएमटीपी प्रोटोकॉल में सीसी या बीसीसी प्राप्तकर्ताओं की धारणा नहीं है; यह मेल क्लाइंट द्वारा आयोजित एक सम्मेलन है। एसएमटीपी सर्वर केवल आम तौर पर रूटिंग जानकारी और डेटा के बारे में परवाह करता है। यह एक महत्वपूर्ण भेद है, क्योंकि इस क्षमता के बिना, बीसीसी मौजूद नहीं हो सका। एक वैध बीसीसी संचार के रूप में निम्नलिखित ग्राहक प्रतिलेख पर विचार करें:

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<anonymous@another-mail-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

अब, इस मामले में, बेनामी को इस बैठक के बारे में एक संदेश भेजा गया था। हालांकि, मेल का यह संस्करण था नहीं जेन डो के लिए भेजा गया; वह बेनामी अधिसूचित होने के बारे में कुछ भी नहीं जानता है। इसके विपरीत, जेन डो को संदेश को एक अलग शरीर और शीर्षलेख के साथ भेजा जाएगा:

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<jane.doe@to-mail-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

यहां, चूंकि बेनामी बीसीसी में था, इसलिए जेन डो को भेजे गए संदेश में बीसीसी प्राप्तकर्ता सूची शामिल नहीं थी। बीसीसी सम्मेलन की वजह से, ईमेल लिफाफा में प्राप्तकर्ता शामिल नहीं हो सकते हैं जो वास्तव में संदेश प्राप्त करते हैं, और इसमें प्राप्तकर्ता भी शामिल हो सकते हैं जो संदेश शीर्षकों में दिखाई नहीं देते हैं।

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

यह कुछ ईमेल अनुपालन नियमों में भी मदद करता है। उदाहरण के लिए, मेल सर्वर में स्वचालित रूप से BCC को एक संग्रह ईमेल सर्वर (सभी भेजे गए सभी ईमेल भी संग्रहीत किए जाते हैं) के लिए कॉन्फ़िगर किए गए नियम हो सकते हैं, इस स्थिति में मेल सर्वर वास्तविक प्राप्तकर्ता भी नहीं हो सकता है।

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<mail-archive@archive-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

यहां, प्राप्तकर्ता एक और पार्टी है जो किसी भी प्राप्तकर्ता या यहां तक ​​कि प्रेषक को पूरी तरह से अनजान है। यह प्रोटोकॉल की एक विशेषता है, आमतौर पर संदेशों को रिले करने या संग्रहीत करने में उपयोग की जाती है।

इस स्पैम संदेश ने क्या किया है उस व्यवहार का लाभ उठाएं। यह एक मानक छेड़छाड़ है कि तकनीकी रूप से किसी भी अनुरूप मेल सर्वर के साथ काम करना चाहिए। बेशक, कई अद्यतन सर्वर डीकेआईएम जैसे "एक्सटेंशन" का उपयोग यह सत्यापित करने के लिए करते हैं कि ऐसा ईमेल प्रामाणिक है, लेकिन वहां अभी भी कई पुराने मेल सर्वर हैं जो परवाह नहीं करते हैं, क्योंकि यह टूटी हुई चीजों को ठीक नहीं करने के लिए मोहक है।

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

tl; डॉ

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


23
2018-05-16 00:33



आपको ध्यान रखना चाहिए कि बीसीसी को अलग करना आम तौर पर है नहीं मेल सर्वर द्वारा प्रबंधित (आपके द्वारा प्रदान की गई SMTP ट्रांसक्रिप्ट अन्यथा सुझाती है, क्योंकि हेल्लो मेल सर्वर की तरह लगता है और एमयूए नहीं)। उस शीर्षलेख में संबोधित व्यक्ति को बीसीसी हेडर के साथ प्रतिलिपि प्रदान करने के लिए दो अलग-अलग ईमेल भेजकर एमयूए द्वारा अतिरिक्त कार्य की आवश्यकता होती है। - Jonas Schäfer
@ जोनासविएलिकी यह एक अच्छा मुद्दा है। मैंने उस प्रभाव में एक संपादन जोड़ा है। - phyrfox
यदि आप किसी वितरित मेल पर बीसीसी लाइन जोड़ते हैं तो यह अब अंधेरा नहीं है :) - eckes
वास्तव में ग्राहक को बीसीसी के मामले में कई संदेश भेजने की आवश्यकता है गलत है। सिर्फ एक संदेश भेजने के लिए यह पूरी तरह से आवाज है। एसएमटीपी ग्राहक एकाधिक सूचीबद्ध कर सकते हैं RCPT TO निर्देश। एकमात्र आवश्यकता यह है कि प्राप्तकर्ता एसएमटीपी सर्वर दोनों प्राप्तकर्ताओं के लिए आधिकारिक सर्वर हो सकता है, या किसी भी के लिए रिले करने के इच्छुक नहीं हो सकता है। - Patrick


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

ईमेल एसएमटीपी प्रोटोकॉल के माध्यम से प्रेषित किया जाता है। एसएमटीपी प्रोटोकॉल अपेक्षाकृत गूंगा है; यह सादे टेक्स्ट को ईमेल पते पर संचारित करने और बहुत कम करने की सुविधा प्रदान करता है। इस सादे पाठ की संरचना द्वारा परिभाषित किया गया है आरएफसी 5322। सामान्य विचार यह है कि ईमेल टेक्स्ट में हेडर नामक मेटाडेटा है, और संदेश का वास्तविक टेक्स्ट बॉडी है। यह ईमेल हेडर प्रेषक द्वारा उत्पन्न होता है (इसमें से कोई भी भरोसा नहीं किया जा सकता है) और इसमें "to:", "from:", "subject:", आदि जैसे फ़ील्ड शामिल हैं ...

एसएमटीपी प्रोटोकॉल (और यह नहीं माना जाता है) मान्य करता है कि ईमेल हेडर एसएमटीपी प्रोटोकॉल में परिभाषित बहुत कम चीजों से मेल खाते हैं, जो अनिवार्य रूप से आपका ईमेल पता और एक प्रेषक ईमेल पता है जिसे कभी भी किसी भी तरह से मान्य नहीं किया जाता है।

ईमेल संदेश में लगभग हर चीज नकली हो सकती है।

ईमेल सामग्री के बारे में आज भी दूरस्थ रूप से भरोसेमंद चीज डीकेआईएम हस्ताक्षर हैं, जो साबित करती हैं कि ईमेल को डोमेन रजिस्ट्रार द्वारा स्वीकृत ईमेल सर्वर के माध्यम से संसाधित किया गया था। गहराई से खोना, आप पाएंगे कि इस घोटाले ईमेल में कोई डीकेआईएम हस्ताक्षर नहीं है।


6
2018-05-15 22:28



मैं फाइनल जोड़ूंगा Received: अपने स्वयं के सिस्टम द्वारा भरोसेमंद भागों में जोड़ा गया हेडर। - Hagen von Eitzen


पता To ईमेल हेडर में सूचना उद्देश्यों के लिए है और यह ईमेल क्लाइंट द्वारा दिखाया गया है। वास्तविक प्राप्तकर्ता का पता दिया गया है RCPT TO एसएमटीपी में यह वही है यदि आप पत्र लिखते हैं, लिफाफे में डालते हैं, लिफाफा पर पता -1 लिखें। फिर कूरियर जाओ, एक और पता-2 दें। कूरियर आपके लिफाफे को बड़े लिफाफा में पता-2 के साथ रखता है और शिपमेंट वहां जाएगा। आपका सचिव (ईमेल क्लाइंट सॉफ़्टवेयर) बाहरी लिफाफे को कचरे में डाल देता है और आपको पता-1 के साथ आंतरिक लिफाफा दिखाता है। आप ईमेल संदेश के रॉ दृश्य के साथ इसे देख सकते हैं।


3
2018-05-16 08:33





हेडर की जांच के आधार पर यह थोड़ा अलग दिखता है। अन्य उत्तरों एसएमटीपी के विवरण को बेहतर तरीके से संभाल सकते हैं।

अगर आप अपने संदेश के पूर्ण शीर्षलेख प्राप्त कर सकते हैं, तो उन्हें अपने पते के लिए खोजें हो सकता है इसे एक क्षेत्र में ढूंढें Envelope-to, Delivered-to या X-Apparently-to। पहला मेरे मेल प्रदाता द्वारा उपयोग किया जाता है, जीमेल द्वारा दूसरा; मैंने तीसरा भी इस्तेमाल किया है। ये अलग-अलग फ़ील्ड हैं लेकिन हमारे उद्देश्यों के लिए एक ही बात का मतलब है: मेलबॉक्स वास्तव में संदेश को वितरित करने के लिए। मैं प्राप्तकर्ता बीसीसीएड के साथ दृष्टिकोण (डेस्कटॉप संस्करण) से भेजकर परीक्षण किया।

मेरा मेल प्रदाता भी इसका उपयोग करता है Delivered-To फ़ील्ड लेकिन उनके सर्वर पर मेलबॉक्स नाम के लिए। यह मेरा ईमेल पता नहीं है हालांकि यह एक जैसा दिखता है (सोचो ChrisH-$ACCOUNTNAME@$SERVER.mail.com)।

दूसरी तरफ आउटलुक (एक्सचेंज सर्वर के साथ संयुक्त) हेडर में प्राप्तकर्ता के ईमेल पते के साथ एक फ़ील्ड शामिल नहीं है यदि आप बीसीसी के रूप में सूचीबद्ध हैं।


2
2018-05-16 08:23