टीएल; डॉ। तल पर।
SMTP प्रोटोकॉल में CC या BCC प्राप्तकर्ताओं की धारणा नहीं है; यह मेल क्लाइंट द्वारा आयोजित एक सम्मेलन है। SMTP सर्वर आमतौर पर केवल राउटिंग जानकारी और डेटा की परवाह करता है। यह एक महत्वपूर्ण अंतर है, क्योंकि इस क्षमता के बिना, बीसीसी मौजूद नहीं हो सकता है। एक वैध बीसीसी संचार के रूप में निम्नलिखित ग्राहक प्रतिलेख पर विचार करें:
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.
.
इधर, चूंकि अनाम बीसीसी में था, इसलिए जेन डो को भेजे गए संदेश में बीसीसी प्राप्तकर्ता सूची शामिल नहीं थी। BCC कन्वेंशन के कारण, ईमेल लिफाफे में वे प्राप्तकर्ता शामिल नहीं हो सकते हैं जो वास्तव में संदेश प्राप्त करते हैं, और इसमें प्राप्तकर्ता भी शामिल हो सकते हैं जो संदेश हेडर में प्रकट नहीं होते हैं।
जैसा कि @JonasWielicki द्वारा उल्लेख किया गया है , जो कि मुझे भी शामिल करना था, यह है कि MUA (मेल उपयोगकर्ता एजेंट) आमतौर पर 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; डॉ
तो, सारांश में, प्रेषक ने एक ईमेल को खराब कर दिया, मूल मेल सर्वर ने इसे स्वीकार / रिले किया, आपके ईमेल सर्वर ने इसे स्वीकार कर लिया और इसे आपके इनबॉक्स में संग्रहीत कर लिया, और आपके ग्राहक ने आपके इनबॉक्स में मौजूद डेटा को ईमानदारी से प्रदर्शित किया, सभी को दरकिनार कर दिया कोई भी सुरक्षा। "Sending" सुरक्षा अक्सर उस परिप्रेक्ष्य में "प्राप्त करना" सुरक्षा की तुलना में बहुत कम प्रतिबंधित है, क्योंकि POP3 को लगभग हमेशा एक मेल बॉक्स तक पहुंचने से पहले एक उपयोगकर्ता नाम और पासवर्ड की आवश्यकता होती है (आप सैद्धांतिक रूप से इसे दरकिनार कर सकते हैं, लेकिन मुझे किसी भी वैध के बारे में पता नहीं है। मेल सेवाएं जो करती हैं)।
