क्या ईमेल पते मामले संवेदनशील हैं?

Question

मैंने पढ़ा है कि मानक के अनुसार ई-मेल का पहला भाग संवेदनशील है, हालाँकि मैंने ई-मेल भेजने की कोशिश की है [e-mail], [e-mail]और [e-mail]यह प्रत्येक मामले में आ चुका है।

मेल सर्वर उपयोगकर्ता नाम कैसे संभालते हैं? क्या यह संभव है कि मामला छूट जाए और वह संदेश नहीं दिया जाएगा? क्या वास्तव में उसी पत्र मामले का उपयोग करना बहुत महत्वपूर्ण है, जैसा कि आपका ई-मेल पता देते समय पंजीकरण करते समय लिखा गया था?

Comments

संबंधित प्रश्न - stackoverflow.com/questions/9013726/…

— ल्यूक गिरविन

Answer 1

से आरएफसी 5321, खंड 2.3.11 :

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

तो हां, "@" से पहले वाला हिस्सा केस-संवेदी हो सकता है, क्योंकि यह पूरी तरह से मेजबान सिस्टम के नियंत्रण में है। हालांकि व्यवहार में, कोई भी व्यापक रूप से इस्तेमाल किया जाने वाला मेल सिस्टम केस के आधार पर विभिन्न पतों को अलग नहीं करता है।

@ चिह्न के बाद का हिस्सा डोमेन है और RFC 1035 , खंड 3.1 के अनुसार ,

"नाम सर्वर और रिज़ॉल्वर को केस-असंवेदनशील तरीके से [डोमेन] की तुलना करनी चाहिए"

संक्षेप में, आप ईमेल पतों को केस-असंवेदनशील मान सकते हैं।

Comments

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

— गीर्ट-जन

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

— पीटर बैगनॉल

क्या कोई ऐसे मेल उत्पादों की सूची के बारे में जानता है, जो (a) उपयोगकर्ता [e-mail] के मान्य होने पर ([e-mail]) को अस्वीकार कर देता है, या (b) दो अलग-अलग मेलबॉक्सेज़ बनाने की अनुमति देगा: John .Doe @ company.com और [e-mail]?

— MSC

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

— मैथ्यू जेम्स ब्रिग्स

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

— Adam111p

Answer 2

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

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

Comments

यह पोस्टेल के नियम en.wikipedia.org/wiki/Robustness_principle का व्यावहारिक अनुप्रयोग है । सॉफ्टवेयर लिखना गलत है जो ईमेल पतों के स्थानीय हिस्सों को मानता है, मामला असंवेदनशील है, लेकिन हाँ, यह देखते हुए कि वहाँ बहुत सारे गलत सॉफ़्टवेयर हैं, यह भी केस सेंसिटिविटी के लिए मजबूत से कम है अगर आप मेल स्वीकार कर रहे हैं ।

— जिग

जिन चीजों से मैं सबसे ज्यादा निराश हूं, उनमें से एक है जो मुझे अपने ईमेल को ऑल-लोअर-केस में लिखने के लिए मजबूर करती है। बस अपने समर्थन साइट के संबंध में उस चीज़ के बारे में Twitch.tv को एक गुस्सा टिप्पणी निकाल दिया। वे आपको अपनी साइट पर ऊपरी-केस दर्ज करने से भी रोकते हैं । इसलिए जब मैं जानता हूं कि मेरा ईमेल सर्वर उन्हें केस-असंवेदनशील मानता है, और मुझे पता है कि RFC बताता है कि यह केस-संवेदी है, साइटों को किसी भी तरह से कोई भी धारणा नहीं बनानी चाहिए और उपयोगकर्ता द्वारा दर्ज किए जाने पर ही गुजरना चाहिए। आदमी है कि बहुत कष्टप्रद है !!!

— मार्क ए। डोनोहे

व्यक्तिगत रूप से, जब मैं अपना ईमेल कहीं लिखता हूं तो मैं मिश्रित मामले का उपयोग करना पसंद करता हूं, इसलिए यह अधिक सुपाठ्य है। उदाहरण के लिए: [e-mail] (मेरा असली पता नहीं।) मैं यह तब भी करता हूं जब मुझे राजधानियों के बिना ईमेल मिलता है।

— पॉलोथ्रोन २२

Answer 3

इस पोस्ट के लिए देर से रास्ता है, लेकिन मैं कुछ अलग कहने के लिए मिल गया है ...

>> "Are email addresses case sensitive?"

खैर, "यह निर्भर करता है ..." (टीएम)

कुछ संगठन वास्तव में सोचते हैं कि यह एक अच्छा विचार है और उनके ईमेल सर्वर केस संवेदनशीलता को लागू करते हैं।

तो, उन पागल स्थानों के लिए, "हां, ईमेल संवेदनशील हैं।"

नोट: सिर्फ इसलिए कि एक विनिर्देशन कहता है कि आप कुछ कर सकते हैं इसका मतलब यह नहीं है कि ऐसा करना एक अच्छा विचार है।

KISS के सिद्धांत पता चलता है कि हमारे सिस्टम केस संवेदी ईमेल का उपयोग करें।

जबकि Robustness सिद्धांत बताता है कि हम केस संवेदनशील ईमेल स्वीकार करते हैं।

समाधान:

• केस संवेदनशीलता के साथ ईमेल स्टोर करें
• केस संवेदनशीलता के साथ ईमेल भेजें
• केस असंवेदनशीलता के साथ आंतरिक खोजें करें

इसका अर्थ यह होगा कि यदि यह ईमेल पहले से मौजूद है: [e-mail]

... और एक अन्य उपयोगकर्ता आता है और इस ईमेल का उपयोग करना चाहता है: [e-mail]

... कि हमारा मामला असंवेदनशील खोज तर्क "एक ईमेल पहले से मौजूद है" त्रुटि संदेश लौटाएगा।

अब, आपके पास एक निर्णय करना है: क्या वह समाधान आपके मामले में पर्याप्त है?

यदि नहीं, तो आप उन क्लाइंट से सुविधा शुल्क ले सकते हैं जो अपने केस संवेदनशील ईमेल के लिए समर्थन की मांग करते हैं और कस्टम लॉजिक को लागू करते हैं जो [e-mail] को आपके सिस्टम में अनुमति देता है, भले ही [e-mail] पहले से मौजूद हो।

किस मामले में आपकी ईमेल खोज / सत्यापन तर्क कुछ इस तरह दिख सकता है:

if (user.paidEmailFee) {
   // case sensitive email
   query = "select * from users where email LIKE ' + user.email + '"
} else {
   // case insensitive email
   query = "select * from users where email ILIKE ' + user.email + '"
}

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

ps ILIKE एक PostgreSQL कीवर्ड है: http://www.postgresql.org/docs/9.2/static/functions-matching.html

Comments

एक सटीक मैच के लिए LIKE / ILIKE एक भयानक विचार है। किसी ईमेल की %संभावना या अधिक होने की कल्पना करें_

— ThiefMaster

आपके अंक बहुत अच्छे हैं! लेकिन आपके उदाहरण के खंड में sql इंजेक्शन इसे बर्बाद कर देता है :(

— epelc

@epelc यह। अधिक सहमत नहीं हो सकता। इस तरह की क्वेरी बिल्डिंग कहीं भी नहीं लिखी जानी चाहिए भले ही यह केवल एक उदाहरण हो।

— xDaizu

@ l3x, जबकि मैं अन्य के रूप में उपरोक्त उदाहरण कोड के खिलाफ दृढ़ता से नहीं हूं, विशेष रूप से क्योंकि आपने इसे स्यूडोकोड के रूप में पुकारा है और यह केवल उदाहरण के लिए है, शायद उपरोक्त सभी टिप्पणियों को आपकी query = ...पंक्तियों को बदलकर संबोधित किया जा सकता है। सरल query = // Insert case-sensitive/insensitive search hereटिप्पणियाँ जो वार्तालाप को SQL इंजेक्शन विषय से दूर रखती हैं और इस पर ध्यान केंद्रित करती हैं कि आप क्या दिखाने की कोशिश कर रहे हैं। दूसरे शब्दों में, इसे तर्क पर रखें, कार्यान्वयन पर नहीं। यह आलोचकों को चुप करा देगा।

— मार्क ए। डोनोहे

Answer 4

RFC 5321 2.4। सामान्य सिंटैक्स सिद्धांत और लेनदेन मॉडल

SMTP कार्यान्वयन मेलबॉक्स स्थानीय-भागों के मामले को संरक्षित करने के लिए आवश्यक है। विशेष रूप से, कुछ मेजबानों के लिए, उपयोगकर्ता "स्मिथ" उपयोगकर्ता "स्मिथ" से अलग है।

मेलबॉक्स डोमेन सामान्य DNS नियमों का पालन करते हैं और इसलिए संवेदनशील नहीं होते हैं

Answer 5

प्रति @ l3x, यह निर्भर करता है।

सामान्य परिस्थितियों के स्पष्ट रूप से दो सेट होते हैं जहाँ सही उत्तर अलग हो सकता है, साथ ही तीसरा भी जो सामान्य नहीं है:

क) आप निजी मेल भेजने वाले उपयोगकर्ता हैं :

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

बी) आप मेल सॉफ्टवेयर विकसित कर रहे हैं :

नीचे RFC5321 2.4 अंश देखें।

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

सी) एक कर्मचारी के रूप में ईमेल पते की व्यावसायिक स्वामित्व वाली सूचियों का प्रबंधन :

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

एक कानूनी दृष्टिकोण से, अगर आप पावती / दोनों पतों से अनुमति के बिना एक डुप्लिकेट निकालें, तो आप जा सकती है जिम्मेदार ठहराया लीक करने के लिए निजी जानकारी / प्रमाणीकरण एक करने के लिए अनधिकृत पते के बस क्योंकि दो वास्तव में-अलग प्राप्तकर्ताओं है विभिन्न मामलों के साथ एक ही पते ।

RFC5321 2.4 से अंश:

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