स्थानीय भाग के अंत में डैश के साथ ईमेल आईडी

Question

यदि ईमेल के स्थानीय भाग के अंत में डैश (-) है तो क्या यह एक वैध ईमेल है? उदाहरण के लिए,

[e-mail]

या सामान्य करने के लिए, इनमें से कोई भी वर्ण ( Characters !#$%&'*+-/=?^_``{|}~ (ASCII: 33, 35-39, 42, 43, 45, 47, 61, 63, 94-96, 123-126)), जो ईमेल आईडी के आरंभ और / या अंत में ईमेल के स्थानीय भाग में होना मान्य है?

Google का कहना है कि यह अमान्य है, इसलिए कुछ समय के लिए मैं इसे भी अमान्य मानता हूँ, हालाँकि RFC स्थानीय भाग को शुरू करने और / या समाप्त करने से केवल [डॉट] चरित्र को बाहर करता है।

नोट: मैं डोमेन भाग के बारे में चिंतित नहीं हूं, क्योंकि DNS जिस तरह से अधिक जटिल हो गया है, जो प्रश्न और उत्तर को जटिल करता है।

https://social.technet.microsoft.com/Forums/ie/en-US/69f393aa-d555-4f8f-bb16-c636a129fc25/what-are-valid-and-invalid-email-address-characters

Comments

अच्छा प्रश्न। क्या आपने इस स्टैक ओवरफ्लो प्रश्न और उत्तर धागे को देखा है ? इस पर बहुत से इसके बारे में पुराने हो चुके जानकारी बहुत बिंदु, लेकिन अभी भी अच्छा प्रारंभिक बिंदु /

— JakeGould

अच्छा संदर्भ लिंक, ऐसा लगता है कि Google उस ईमेल को अमान्य मानता है, जबकि Microsoft को कोई समस्या नहीं है।

— जिमसन कन्ननथारा जेम्स

Google द्वारा लाए जाने के बाद से इसे साझा करना: Gmail एक ईमेल पते में किसी भी अवधि को अनदेखा करता है, इसलिए यदि आपका ईमेल "[e-mail]" था, तो आपको "[e-mail]" पर भेजा गया मेल भी प्राप्त होगा। यह ईमेल पते के अंत में प्लसस को भी अनदेखा करता है: "[e-mail]"।

— मोवल्कलर

अपनी स्वयं की मेल सेवा पर मैं उपयोगकर्ता नाम से "u" अक्षर को प्रतिबंधित कर सकता हूं। सिर्फ इसलिए कि।

— Agent_L

Answer 1

यदि ईमेल के स्थानीय भाग के अंत में डैश (-) है तो क्या यह एक वैध ईमेल है? [...] Google कहता है कि यह अमान्य है, इसलिए कुछ समय के लिए मैं इसे भी अमान्य मानता हूँ, हालाँकि RFC स्थानीय भाग को शुरू करने और / या समाप्त करने से केवल [dot] चरित्र को बाहर रखता है।

यह मान्य है। आप इसे केवल Google द्वारा अस्वीकार किए जाने के कारण देख रहे हैं क्योंकि यह पूरी तरह से अलग जाँच करता है - उनकी अपनी नीतियां हैं जो स्थानीय-भाग हो सकती हैं, जैसा कि कई अन्य प्रदाता करते हैं।

---

Google, या कोई अन्य, सभी संभवतः मान्य ईमेल पतों को स्वीकार करने के लिए बाध्य होगा, यदि फॉर्म वास्तव में एक मौजूदा, वैध ईमेल पते (प्रदाता से संभवतः) के लिए पूछ रहा हो । उदाहरण के लिए, यह एक त्रुटि होगी यदि Gmail का To: / Cc: फ़ील्ड ने एक वैध पते को अस्वीकार कर दिया।

लेकिन आपके द्वारा हाइलाइट किया गया फ़ील्ड आपको मौजूदा ईमेल पते के लिए नहीं पूछता है; यह Google सिस्टम पर एक खाता नाम के लिए पूछता है , जो एक बार खाता बनाने के बाद केवल एक ईमेल पते के लिए आधार होगा। ऐसा कुछ भी नहीं है जो Google, या किसी और को अपने स्वयं के सिस्टम पर मान्य खाता नामों (या, वास्तव में, यहां तक ​​कि मेलबॉक्स नाम) के सेट को सीमित करने से मना करे ।

या, दूसरे शब्दों में, 'स्थानीय-भाग' के लिए अनुमत वर्णों को परिभाषित करने का अर्थ केवल यह है कि मेल एप्लिकेशन SMTP सर्वर को RFC 822 हेडर और SMTP कमांड में ऐसे पते स्वीकार करने चाहिए - लेकिन यह इस तरह के मेलबॉक्स बनाने में सक्षम होने के बारे में कुछ नहीं कहता है । (वास्तव में, जब प्रारंभिक ईमेल RFC लिखे गए थे और अधिकांश मेलबॉक्स अभी भी OS- स्तर के खातों से जुड़े हुए थे, तो उनके नाम समान या यहां तक ​​कि कठोर सीमाएँ थे।)

उदाहरण के लिए, RFC 5321 का यह हिस्सा (ABNFs के नीचे धारा 4.1.2) स्पष्ट रूप से कहता है कि एक प्राप्त मेजबान को अनुमति दी जाती है और वास्तव में उसके अपने मेलबॉक्स के नाम कैसे हैं, इस पर बहुत कड़ी सीमाएं होनी चाहिए :

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

इसलिए, हालाँकि [e-mail] यह वाक्यात्मक रूप से मान्य है , लेकिन इसका मतलब यह नहीं है कि Google को आपको इसे बनाने की अनुमति देनी चाहिए।

Comments

एक दिलचस्प पक्ष के रूप में, Google ईमेल पतों ( gmail.googleblog.com/2008/03/… ) में अवधियों को अनदेखा करता है , जो RFC में भी निर्दिष्ट नहीं है। तो, [e-mail] [e-mail] या [e-mail] के समान ही है।

— चाइल्डोफॉन्ग

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

— माइकल जूनियर

@grawity ओह मुझे पता है - मैं एक और चीज़ का उदाहरण देने के लिए टिप्पणी कर रहा था जो कि RFC में निर्दिष्ट नहीं है लेकिन अनुमति है।

— चाइल्डोफॉन्ग

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

— माइकल जूनियर

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

— कुमारहर्ष

Answer 2

जी सूट (औपचारिक रूप से आपके डोमेन के लिए Google ऐप्स) अंतिम पते के रूप में ईमेल पते के भीतर भी हाइफ़न (डैश) की अनुमति देता है।

उपयोगकर्ता नाम में अक्षर (az), संख्याएँ (0-9), डैश (-), अंडरस्कोर (_), एपोस्ट्रोफ़ ('), और अवधियाँ (।) हो सकती हैं।

स्रोत: नाम और पासवर्ड दिशानिर्देश

जैसा कि आपने बताया, जीमेल ईमेल पतों में हाइफ़न की अनुमति नहीं देता है।