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

Question

मैंने पढ़ा है कि ई-मेल के मानक पहले भाग से मामला संवेदनशील है, हालांकि मैंने name@example.com, Name@example.com और NAME@example.com पर ई-मेल भेजने की कोशिश की है - यह प्रत्येक मामले में पहुंच गया है।

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

Answer 1

आरएफसी 5321 से

, खंड-2.3.11:

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

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

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

"नाम सर्वर और रिसोल्वर एक केस-संवेदी ढंग से [डोमेन] की तुलना चाहिए"

संक्षेप में, आप ईमेल पते को केस-असंवेदनशील के रूप में इलाज करने के लिए सुरक्षित हैं।

Answer 2

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

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

Answer 3

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

>> "Are email addresses case sensitive?" 

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

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

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

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

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

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

समाधान:।

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

इसका मतलब यह होगा कि अगर यह ईमेल पहले से मौजूद के साथ आंतरिक खोज कर सकते: user@x.com

... और दूसरा उपयोगकर्ता साथ आता है और इस ईमेल का उपयोग करना चाहता है: USER@x.com

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

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

यदि नहीं, तो आप उन ग्राहकों को सुविधा शुल्क ले सकते हैं जो उनके केस संवेदनशील ईमेल के लिए समर्थन मांगते हैं और कस्टम लॉजिक लागू करते हैं जो USER@x.com को आपके सिस्टम में अनुमति देता है, भले ही user@x.com पहले से मौजूद है ।

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

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 + '" 
} 

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

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

Answer 4

आरएफसी 5321 2.4। जनरल सिंटेक्स सिद्धांतों और लेन-देन मॉडल

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

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

Answer 5

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

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

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

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

RFC5321 देखें 2.4 नीचे स्थित अंश:

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

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

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

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

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

अंश:

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

Answer 6

मैं केवल केस संवेदनशीलता के साथ ईमेल पुनर्प्राप्त करने के लिए एक उपयोगी कारण के बारे में सोच सकता हूं: स्पैम से बचें। अपने दोस्तों और सहयोगियों को बताएं कि उन्हें ऊपरी और निचले मामले के उचित संयोजन का उपयोग करना चाहिए। (MyEmAiL @ डोमेन।कॉम) मुझे लगता है कि स्पैमर ऐसे नियमों का पालन करने की संभावना नहीं रखते हैं, खासकर जब आपका पता सर्वर से सर्वर तक पास हो जाता है।

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

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