2009-10-01 8 views
12

सिद्धांत ईमेल में case sensitive हैं। लेकिन सिस्टम लॉगिन के रूप में ईमेल का उपयोग करके मैं चाहता हूं कि वे सभी कम मामले हों (यानी [email protected] और [email protected] अलग-अलग उपयोगकर्ता नहीं हो सकते हैं)।क्या मैं सुरक्षित रूप से ईमेल पते को कम मामले का इलाज कर सकता हूं?

क्या यह कुछ उपयोगकर्ताओं के लिए समस्या हो सकती है जो उनके ईमेल पते में केस संवेदनशीलता का उपयोग करते हैं? कोई इसका उपयोग वहां करता है?

संपादित करें: क्योंकि बहुत से लोग "सहेजने के मामले को सुरक्षित रखें, लॉगिन पर अनदेखा करें" उत्तर: यदि मेरे पास वास्तव में दो अलग-अलग उपयोगकर्ता जॉन @ स्मिथ और जॉन @ स्मिथ हैं तो यह सिस्टम टूट जाएगा, है ना?

उदाहरण: जॉन @ स्मिथ और जॉन @ स्मिथ के पास पासवर्ड 123 है। मुझे कैसे पता चलेगा कि किसने अभी प्रमाणित किया है?

+2

मुझे लगता है कि * कोई * इसका उपयोग करता है। लेकिन यह उनकी समस्या है – SilentGhost

+1

@SilentGhost: यह नहीं कह सकता कि मैं आपसे सहमत हूं - यह डेवलपर्स के रूप में हमारी समस्या है, और उस पर एक बहुत ही सरल है;) – RedFilter

उत्तर

6

कुछ सिस्टम केस संवेदनशील हैं।

मैं सुझाव दूंगा कि इसे संरक्षित किया जाए लेकिन ला विंडोज फाइल सिस्टम को नजरअंदाज कर दिया जाए।

यानी याद रखें जॉन ने जॉन@smith.com के साथ साइन अप किया है लेकिन उसे [email protected], [email protected] या [email protected] के रूप में लॉग इन करने दें।

संघर्षों का कारण बनने की संभावना नहीं है और यदि किसी के पास केस-संवेदी ईमेल है तो मुझे यकीन है कि वे इसके बारे में अवगत होंगे।

+1

कृपया मेरा संपादन देखें। मुझे लगता है कि यह केवल तभी काम करेगा जब मैंने मामलों को संरक्षित किया लेकिन एक ही पत्र के साथ किसी भी नए पंजीकरण को रोक दिया लेकिन विभिन्न मामलों, जो पूरे मामले की संवेदनशीलता की बात करते हैं, नहीं? –

+0

यह वही है जो मैं – wefwfwefwe

+0

का सुझाव दे रहा हूं, मुझे पता है कि यह धागा थोड़ा पुराना है, लेकिन मुझे एक ऐसा विचार था जो कुछ की मदद कर सकता है। आप हमेशा एक संरक्षित रिकॉर्ड और निचले-आधारित रिकॉर्ड दोनों को स्टोर कर सकते हैं। अपने चेक के लिए निचले-चरण वाले रिकॉर्ड का उपयोग करें, और अपने ईमेल के लिए संरक्षित रिकॉर्ड का उपयोग करें। – diggersworld

0

हाँ, यह एक समस्या है। मैंने अभी लिनक्स पर एक छोटा परीक्षण किया है (एक्ज़िम चल रहा है) और केवल सही केस वाला मेल मेलबॉक्स तक पहुंच गया है ...

मुझे लगता है कि अधिकतर वाणिज्यिक मेल प्रदाता सभी ईमेल पते सामान्य करते हैं लेकिन सामान्य रूप से आपको सही केस का उपयोग करना होगा !

0

This link कहता है कि "शायद ही कोई ईमेल सेवा या आईएसपी केस संवेदनशील ईमेल पते को लागू करता है"।

+4

अनुवाद: कुछ ईमेल सेवाएं/आईएसपी केस संवेदनशील ईमेल पते को लागू करती हैं। – Bill

+0

एक और अनुवाद: इससे कोई फर्क नहीं पड़ता, सिवाय इसके कि यह कब होता है। – RedFilter

0

मुझे किसी भी कार्यान्वयन के बारे में पता नहीं है जो एक ही पत्र वाले ईमेल पते के बीच अंतर करता है लेकिन विभिन्न मामलों में।

मैंने कभी ऐसा संदेश नहीं सुना है जो मामलों को गलत तरीके से प्रेषित नहीं किया जा रहा है क्योंकि मामले गलत थे।

13

RFC 2821 के अनुसार:

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

तो, जब आप केस संवेदनशीलता के साथ ईमेल पते का इलाज कर सकते हैं, तो आप ऐसा करने से निराश हैं।

+0

मैंने उस अनुच्छेद को पढ़ा (मेरे प्रश्न में उससे जुड़ा हुआ है) लेकिन क्या यह एक हां या नहीं है? वास्तविक दुनिया प्रणालियों में यह कितना लागू है? –

+1

यह "सुरक्षित" के अधिकांश मूल्यों के लिए हाँ है। आपको किसी समस्या का सामना नहीं करना पड़ेगा और यदि आप ऐसा करते हैं, तो कार्य-आसपास (एक अलग पता का उपयोग करके) उपयोगकर्ता-अनुभव की समस्याओं से आसान है जो आप मामले को लागू करके करेंगे। –

0

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

5

आईएमएचओ स्टोर को उपयोगकर्ता द्वारा दर्ज किए जाने के तरीके को स्टोर और प्रदर्शित करता है, न केवल इसलिए कि आरएफपी का कहना है कि आपको मामले का सम्मान करना है, लेकिन क्योंकि यदि उपयोगकर्ता की वरीयता है, तो आपको उस वरीयता का सम्मान करना चाहिए। यह है ईमेल पता। मैं उन व्यक्तिगत विवरणों को दोबारा सुधारने वाले सिस्टम का प्रशंसक नहीं हूं जो मैं उन्हें प्रदान करता हूं।उदाहरण के लिए, आपको आश्चर्य होगा कि मुझे "टीजे" कहने पर INSIST कितने सिस्टम हैं - जो स्पष्ट रूप से गलत है - "टीजे" के बजाय (इसे सही करने के लिए SO को +1 करें)।

तो यदि जॉन स्मिथ "[email protected]" के रूप में साइन अप करता है, तो जॉन स्मिथ अपना ईमेल पता देखना चाहता है (अगर उसे प्राथमिकता है)। मैं शायद किसी और को "[email protected]" ईमेल पते से साइन अप नहीं करने दूंगा क्योंकि बाधाएं भारी हैं कि यह दूसरे खाते के पते जैसा ही है, लेकिन मैं उपयोगकर्ता के पते या अन्य विवरणों के स्वरूपण के बारे में नहीं सोचूंगा। अधिक से अधिक मैं उन्हें संकेत दे सकता हूं अगर वे मुझे सभी कैप्स शॉर्टिंग देते हैं, यह पूछते हुए कि क्या वे कुछ और पसंद नहीं करेंगे ... कोमल।

12

डेटा को फेंक न दें। स्ट्रिंग के दोनों सिरों को ट्रिम करने के अपवाद के साथ, ईमेल पता या उपयोगकर्ता नाम ठीक उसी तरह स्टोर करें जैसा आपने प्राप्त किया था।

ईमेल ईमेल भेजते समय, उपयोगकर्ता द्वारा प्रदान किए गए मामले का उपयोग करें। सिर्फ इसलिए कि मामला-संवेदनशीलता दुर्लभ है, इसे संभालने का कोई कारण नहीं है - अन्यथा उपयोगकर्ता को कोई मेल नहीं मिलता है, और संभवतः यहां तक ​​कि पंजीकरण भी नहीं कर सकता है।

उपयोगकर्ता को प्रमाणित करते समय, आप वैकल्पिक रूप से निचले मामले (या ऊपरी मामले) तारों पर तुलना कर सकते हैं, ताकि मामले को नजरअंदाज कर दिया जा सके।

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

संबंधित मुद्दे

 संबंधित मुद्दे