क्या BCCing ई-मेल विश्वसनीय होने की गारंटी है?


29

दूसरे शब्दों में, क्या यह एक सुरक्षित धारणा है कि कोई भी प्राप्तकर्ता कभी बीसीसी में ई-मेल नहीं देखेगा? क्या होगा यदि प्राप्तकर्ता अपने (लेकिन प्रेषक के) मेल सर्वर का व्यवस्थापक नहीं है और अपने सर्वर पर कोई संशोधन कर सकता है?


15
आम तौर पर ईमेल सुरक्षित नहीं है और विश्वसनीय नहीं है। यदि प्राप्तकर्ता अपने सर्वर का एक व्यवस्थापक है तो वह इसके लिए बहुत कुछ कर सकता है।
लॉर्ड पीटर

क्या यह लायक है के लिए मैं सिर्फ इस एटीएम के साथ एक मुद्दा रहा हूँ। stackoverflow.com/questions/31527974/…
johnsnails

जवाबों:


21

सं। SMTP स्टोर-एंड-फॉरवर्ड विधियों का उपयोग करके एक सादा प्रोटोकॉल है ।

इसका क्या मतलब है:

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

दूसरे शब्दों में, आपकी धारणा असुरक्षित है। यदि आप गोपनीयता और सुरक्षा चाहते हैं, तो डिजिटल हस्ताक्षर और एन्क्रिप्शन का उपयोग करें, उदाहरण के लिए GPG; वेनिला ई-मेल ऐसी नौकरी के लिए एक गलत उपकरण है।


1
एन्क्रिप्शन कैसे प्राप्तकर्ताओं को छिपाने की समस्या को हल करता है?
detly

यह नहीं है, लेकिन गोपनीयता के संदर्भ में, पिस्कवर आवश्यक रूप से संदेश के प्राप्तकर्ता मेलबॉक्स के बारे में बात नहीं कर रहा था, केवल सामग्री। AFAIK, यह आम तौर पर ईमेल के प्राप्तकर्ताओं को छिपाने के लिए संभव नहीं है जब तक कि इसे गैर-लॉगिंग प्रॉक्सी के माध्यम से आगे नहीं बढ़ाया जा सके। यदि आपका संदेश इतना गुप्त है कि आपको प्राप्तकर्ताओं के साथ-साथ सामग्री को भी मुखौटा बनाने की आवश्यकता है, तो आपको एक अन्य संचार तंत्र खोजने की आवश्यकता है।
दोपहर

2
मैं आखिरी वाक्य तक पिस्कोवर के साथ था। यदि आप सभी प्राप्तकर्ता को एक-दूसरे से छुपाना चाहते हैं, तो आपको बस एक मेल क्लाइंट की आवश्यकता है जो सभी बीसीसी को व्यक्तिगत रूप से भेज सके।
स्टीव बेनेट

@afrazier: क्या मैंने पहले से ही एक प्रतिस्पर्धात्मक उत्तर नहीं जोड़ा था, मैंने ओपी के प्रश्न का उत्तर नहीं देने के लिए इसे नीचे कर दिया था।
Blrfl

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

13

कोई भी मेल ट्रांसफर एजेंट (MTA) जो पूरी तरह से RFC 2822 (विशेष रूप से, खंड 3.6.3, गंतव्य पता फ़ील्ड ) का अनुपालन करता है, Bcc:वितरण का प्रयास करने से पहले हेडर से फ़ील्ड को हटा देगा , जिससे नेत्रहीन प्राप्तकर्ता के लिए नेत्रहीन प्राप्तकर्ता निर्धारित करना असंभव हो जाएगा 'पहचान।

वहाँ कैच के एक जोड़े हैं:

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

  • तथ्य यह है कि आपके पास एक प्राप्तकर्ता से एक ईमेल जो एक या एक से अधिक एमटीए को अंधा-कॉपी किया गया हो सकता है, उन एमटीए के लॉग में जीवित रह सकता है।


1
महान जवाब विशेष रूप से संबोधित करते हुए "प्राप्तकर्ता में से कोई भी कभी भी बीसीसी में ई-मेल [पते] नहीं देखेगा"। आप ईमेल द्वारा उत्तर-बॉट को ईमेल भेजकर बीसीसी हेडर के साथ अपने पहले एमटीए का परीक्षण कर सकते हैं जो आपके ईमेल का हेडर लौटाता है।
sabre23t

MTA को Bcc:हेडर देखने के लिए भी नहीं माना जाता है ; इसके बजाय, MUA (मेल क्लाइंट प्रोग्राम) को SMTP लिफाफे ( MAIL FROM) में सभी पते निर्दिष्ट करने चाहिए ।
ग्रैविटी

यह चाल सभी मामलों में काम नहीं करेगी क्योंकि मानकों को उस डिलीवरी की आवश्यकता नहीं होती है जो कि हेडर के बाहर प्राप्तकर्ता का पता दे सकती है। MTP तब तक मौजूद नहीं था जब तक BCC व्यवहार पहली बार परिभाषित नहीं किया गया (RFC 680, 1975 में); एक साल बाद एसएमटीपी आया।
11

5

आपको कभी भी यह नहीं मानना ​​चाहिए कि प्राप्तकर्ता बीसीसी प्राप्तकर्ता के बारे में जागरूक नहीं होंगे। मैंने अपने मेल प्रोग्राम में BCCed प्राप्तकर्ताओं को "रिप्लाई ऑल" हिट कर दिया है, और हर किसी को मेल की प्राप्ति से पहले ही इसकी घोषणा कर दी है, जो कि BCCed होने का वास्तव में मतलब होने की समझ की कमी है। यदि आपको वास्तव में निजी होने की आवश्यकता है, तो मूल प्रेषकों को भेजने के बाद अपने प्रेषित फ़ोल्डर से संदेश को अग्रेषित करें, इसलिए संदेश शीर्षलेखों में केवल दूसरा पता आपका है।

कहा कि, भले ही आपने BCC का उपयोग किया हो, जब तक कि BCCed प्राप्तकर्ता का सर्वर मूल प्राप्तकर्ता से अलग होता है, प्राप्तकर्ता के सर्वर तक BCC की जानकारी नहीं होगी, क्योंकि इसे छीन लिया गया होगा (या अधिक संभावना कभी शामिल नहीं की गई थी) संदेश प्रदाता) आपके प्रदाता के मेल सर्वर द्वारा।

एक तरफ ध्यान दें: एसएमटीपी न तो विश्वसनीय है, विशेष रूप से निजी नहीं है। कुछ पोस्टरों का दावा है कि सर्वरों के एसएमटीपी "चेन" मौजूद हैं, लेकिन सामान्य तौर पर, एसएमटीपी आपके कंप्यूटर से आपके आईएसपी को, प्राप्तकर्ता आईएसपी को भेजता है। (और हालांकि कई सर्वर उनके पास आंतरिक रूप से होते हैं) सामान्य तौर पर, आपके मेल को किसी तीसरे पक्ष के मेल सर्वर पर रूट नहीं किया जाएगा, और वास्तव में इस तरह के प्रयासों को आम तौर पर विरोधी स्पैम कारणों से अस्वीकृत कर दिया जाता है। (अपवाद हैं, क्योंकि छोटे प्रदाता और घरेलू नेटवर्क उनके प्रदाता को अग्रेषित करेंगे, लेकिन यह नियम नहीं है)

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

एफबीआई नियमित रूप से कार्निवोर और अन्य कार्यक्रमों के माध्यम से ऐसा करता है, और दुष्ट तत्वों को अतीत में भी ऐसा करते हुए प्रलेखित किया गया है।


1
I've had BCCed recipients hit "Reply All" in their mail program मेरे साथ ऐसा कभी नहीं हुआ है, लेकिन मैंने देखा है कि ऐसा कई बार हुआ है। आपकी सलाह (Bcc नहीं, लेकिन भेजने के बाद आगे) ठीक वैसा ही है जैसा मैं भी करता हूं। मुझे घमंडी की तरह आवाज करने से नफरत है, लेकिन कभी-कभी आपको लोगों को खुद से बचाना पड़ता है।
दान .११

@ Dan7119 मुझे लगता है कि .. क्या आप / आप भी एक संत हैं?
SplinterReality

बहुत बढ़िया जवाब। भले ही BCC की जानकारी अलग से 100% विश्वसनीय हो, मानव कारक BCCed recipients hit "Reply All"विश्वसनीय होने की गारंटी नहीं है। मैं forward the message from your Sent folderविशेष रूप से गैर-तकनीकी प्रेमी बीसीसीआई प्राप्तकर्ताओं जैसे सीईओ के लिए सहमति देता हूं ।
sabre23t

1

आपके ईमेल क्लाइंट या सर्वर (पता नहीं है) को संदेश भेजने से पहले BCC की जानकारी निकाल लेनी चाहिए। यदि आप किसी संदेश पर अपने आप को BCC करते हैं और फिर स्रोत देखते हैं, तो आपको अपना ईमेल पता कहीं भी नहीं मिल सकता है, सिवाय From लाइन के (यह मेरे अपने मेल से सत्यापित)।


धन्यवाद। लेकिन मेरा प्रश्न वास्तव में गहरा है और विश्वसनीयता और सुरक्षा के बारे में है। यह नहीं है कि यह सिद्धांत में कैसे माना जाता है।
क्वर्टी

खैर, जहां तक ​​मुझे पता है, यह देखने का तरीका है कि क्या सिद्धांत अभ्यास से मेल खाता है, तो खुद को ईमेल पर बीसीसी करें, स्रोत देखें, और देखें कि क्या बीसीसी का पता है।
ज़प्लेन

आपका ईमेल क्लाइंट BCC जानकारी नहीं छीनता है। इसका कोई मतलब नहीं है।
स्टीव बेनेट

1

यह सब सर्वर पर निर्भर करता है। अधिकांश सर्वर बीसीसी लाइन को ले लेंगे और मूल रूप से प्रति पते पर एक बार संदेश भेजेंगे। मूल रूप से cc लाइन सेंड में bcc एड्रेस डालते हैं, अगला पता cc लाइन में भेजते हैं और टाइप चीज भेजते हैं। लेकिन यह सब मेल सर्वर सेटअप पर निर्भर करता है। बीसीसी को आपके आउटगोइंग मेल सर्वर से आगे कभी नहीं जाना चाहिए।


7
तीन बिंदुओं पर गलत। सबसे पहले, यह MUAs है, SMTP सर्वर नहीं है, जो Bcc:हेडर के साथ सौदा करते हैं। जब तक चीजें एसएमटीपी सर्वर तक पहुंचती हैं, तब तक प्राप्तकर्ता के पते लिफाफे में होते हैं , हेडर के नहीं। दूसरा, केवल SMTP सबमिशन सर्वर कभी भी ऐसे हेडर को पहले स्थान पर लिखते हैं। तीसरा, संदेश हमेशा एक बार लिफाफा प्राप्तकर्ता को भेजे जाते हैं । यह विशेष या भिन्न नहीं है।
JDBP

1

डिजिटल हस्ताक्षर या एन्क्रिप्शन के बिना नेट पर यात्रा करने वाली हर चीज को आसानी से संशोधित किया जा सकता है। यदि आपको ईमेल के लिए एंड-टू-एंड अखंडता की आवश्यकता है, तो PGP / GPG हस्ताक्षर का उपयोग करें।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.