ईमेल पते में किन वर्णों की अनुमति है?

639

मैं पूर्ण ईमेल सत्यापन के बारे में नहीं पूछ रहा हूँ।

मैं सिर्फ यह जानना चाहता हूं कि ईमेल पते के कुछ हिस्सों user-nameऔर serverभागों में क्या अनुमति है । इसकी देखरेख की जा सकती है, हो सकता है कि ईमेल एड्रेस अन्य रूप ले सकें, लेकिन मुझे इसकी परवाह नहीं है। मैं केवल इस सरल रूप के बारे में पूछ रहा हूं: user-name@server(जैसे wild.wezyr@best-server-ever.com) और दोनों भागों में वर्णों की अनुमति दी।

— WildWezyr
स्रोत

184

की +अनुमति है। यह मुझे पागल कर देता है जब वेब साइट्स इसे अनुमति नहीं देती हैं क्योंकि मेरे ईमेल +में यह है और कई साइटें इसकी अनुमति नहीं देती हैं।

— डैन हर्बर्ट

42

मुझे लगता है कि चश्मा को लिंक देना महत्वपूर्ण है, जैसा कि आप वास्तव में उस अधिकार को प्राप्त करना चाहते हैं, और यही वह युक्ति है जिसमें आप आते हैं। यदि आप युक्ति को पढ़ने और समझने के लिए बहुत आलसी हैं, तो कृपया ईमेल पते में अनुमत वर्णों के लिए जाँच छोड़ दें। जो लोग उस स्टफ की परवाह करते हैं।

— १२:१० बजे

9

एक ही सामग्री को कवर करने वाले पहले प्रश्न: stackoverflow.com/questions/760150/ । दुखद बात यह है कि भले ही यह सवाल इस से लगभग 8 महीने पुराना है, पुराने सवाल के बेहतर जवाब हैं। नीचे दिए गए लगभग सभी उत्तर पहले से ही पुराने थे, जब वे मूल रूप से पोस्ट किए गए थे। विकिपीडिया प्रविष्टि देखें (और चिंता न करें, इसके प्रासंगिक आधिकारिक संदर्भ हैं )।

— जॉन वाई

10

कई उत्तरों के विपरीत, ईमेल पते के स्थानीय भाग में रिक्त स्थान की अनुमति दी जाती है, यदि उद्धृत किया गया हो। "hello world"@example.comयह सही है।

— user253751

3

@LaraRuffleColes - जीमेल के लिए, जब आप एक ईमेल खाता बनाते हैं, तो यह आपको "+" चिह्न वाले पते बनाने की अनुमति नहीं देता है। "+" चिह्न ("प्लस-एड्रेसिंग") किसी को भी एक जीमेल पते के साथ एक "वैकल्पिक" बनाने के लिए एक "स्ट्रिंग" के बाद एक "वैकल्पिक" ("उपनाम") ईमेल पते को जोड़ने के लिए एक जीमेल पते के साथ किसी को भी अनुमति देता है। अपने खाते के लिए उपयोग करने के लिए। उदाहरण: "example@gmail.com", "example+tag@gmail.com"। इसका एक विशिष्ट (और शायद "प्राथमिक") उपयोग आपके खाते के लिए अन्य ईमेल पते बनाने में सक्षम होने के लिए है जो आपको आने वाले ईमेल संदेशों को टैग करने और फ़िल्टर करने की अनुमति देता है, सैद्धांतिक रूप से प्रेषक द्वारा फ़िल्टर किया गया है।

— केविन फेगन

797

RFC 5322 देखें : इंटरनेट संदेश प्रारूप और, कुछ हद तक, RFC 5321: सरल मेल स्थानांतरण प्रोटोकॉल ।

RFC 822 में ईमेल पते भी शामिल हैं, लेकिन यह ज्यादातर इसकी संरचना से संबंधित है:

 addr-spec   =  local-part "@" domain        ; global address     
 local-part  =  word *("." word)             ; uninterpreted
                                             ; case-preserved

 domain      =  sub-domain *("." sub-domain)     
 sub-domain  =  domain-ref / domain-literal     
 domain-ref  =  atom                         ; symbolic reference

और हमेशा की तरह, विकिपीडिया का ईमेल पतों पर एक अच्छा लेख है :

ईमेल पते का स्थानीय हिस्सा इनमें से किसी भी ASCII वर्ण का उपयोग कर सकता है:

अपरकेस और लैटिन पत्र लोअरकेस Aकरने के लिए Zऔर aकरने के लिए z;

अंकों 0को 9;

विशेष वर्ण !#$%&'*+-/=?^_`{|}~;

डॉट ., बशर्ते कि यह उद्धृत किए बिना पहला या अंतिम चरित्र नहीं है, और यह भी प्रदान किया जाता है कि यह लगातार प्रकट नहीं होता है जब तक कि उद्धृत नहीं किया जाता है (उदाहरण John..Doe@example.comकी अनुमति नहीं है लेकिन "John..Doe"@example.comअनुमति दी गई है);

अंतरिक्ष और "(),:;<>@[\]पात्रों को प्रतिबंध के साथ अनुमति दी जाती है (उन्हें केवल एक उद्धृत स्ट्रिंग के अंदर अनुमति दी जाती है, जैसा कि नीचे दिए गए पैराग्राफ में वर्णित है, और इसके अलावा, बैकस्लैश या दोहरे-उद्धरण को बैकस्लैश से पहले होना चाहिए);

स्थानीय-भाग के किसी भी छोर पर कोष्ठक के साथ टिप्पणियों की अनुमति है; जैसे john.smith(comment)@example.comऔर (comment)john.smith@example.comदोनों के बराबर हैं john.smith@example.com।

एएससीआईआई पात्रों के अलावा, 2012 तक आप ऊपर दिए गए अंतर्राष्ट्रीय पात्रों का उपयोग कर सकते हैं U+007F, जो कि यूएफसीएफ -8 के रूप में एन्कोडेड हैं जैसा कि आरएफसी 6532 कल्पना में वर्णित है और विकिपीडिया पर समझाया गया है । ध्यान दें कि 2019 तक, ये मानक अभी भी प्रस्तावित के रूप में चिह्नित हैं, लेकिन धीरे-धीरे लुढ़का जा रहा है। इस कल्पना में परिवर्तन अनिवार्य रूप से की तरह की अनुमति दी और प्रतिबंधित विशेष वर्ण पर नियमों को प्रभावित किए बिना वैध अक्षरांकीय वर्णों (atext) के रूप में अंतर्राष्ट्रीय वर्ण जोड़ा !#और @:।

सत्यापन के लिए, ईमेल पते को मान्य करने के लिए एक नियमित अभिव्यक्ति का उपयोग करना देखें ।

domainभाग परिभाषित किया गया है इस प्रकार है :

इंटरनेट मानकों (टिप्पणियों के लिए अनुरोध) प्रोटोकॉल के लिए जनादेश घटक होस्ट नाम लेबल केवल ASCII अक्षर हो सकते हैं कि aके माध्यम से z(एक केस-संवेदी ढंग से), अंकों 0के माध्यम से 9, और हाइफन ( -)। RFC 952 में होस्टनामों का मूल विनिर्देश , अनिवार्य है कि लेबल एक अंक या एक हाइफ़न के साथ शुरू नहीं कर सकते हैं, और एक हाइफ़न के साथ समाप्त नहीं होना चाहिए। हालाँकि, बाद के विनिर्देशन ( RFC 1123 ) ने होस्टनाम लेबल को अंकों के साथ शुरू करने की अनुमति दी। कोई अन्य प्रतीक, विराम चिह्न वर्ण या रिक्त स्थान की अनुमति नहीं है।

— एंटोन गोगोलेव
स्रोत

15

@WildWzyr, यह इतना आसान नहीं है। ईमेल पतों में अनुमति दी गई नियमों के बहुत सारे नियम हैं। उन सभी को सूचीबद्ध करने की तुलना में कल्पना को संदर्भित करना सरल है। यदि आप पूरा रेगेक्स चाहते हैं, तो यह जानने के

— Dan Herbert

6

कोई सरल सूची नहीं है, सिर्फ इसलिए कि आप कुछ सरल चाहते हैं इसका मतलब यह नहीं है कि ऐसा होगा। कुछ वर्ण केवल कुछ स्थानों पर हो सकते हैं और अन्य में नहीं। आपके पास वह नहीं हो सकता जो आप हर समय चाहते हैं।

15

@WildWezyr खैर, पूर्ण-रोक चरित्र को स्थानीय-भाग में अनुमति दी गई है। लेकिन शुरुआत या अंत में नहीं। या एक और पूर्ण विराम के साथ। तो इसका उत्तर उतना आसान नहीं है, जितना कि अनुमति प्राप्त पात्रों की एक सूची है, ऐसे नियम भी हैं कि उन वर्णों का उपयोग कैसे किया जा सकता है - .ann..other.@example.comएक वैध ईमेल पता नहीं है, लेकिन ann.other@example.comफिर भी, दोनों समान वर्णों का उपयोग करते हैं।

— मार्क पिम

14

यह भी याद रखें कि अंतर्राष्ट्रीय डोमेन नाम आने के साथ, अनुमत वर्णों की सूची में विस्फोट हो जाएगा।

— चिन्मय कांची

50

अंतर्राष्ट्रीय पतों के कारण यह मान्य उत्तर नहीं है। देखिए मेसन का जवाब

— ZacharyP

329

ध्यान रहे! इस धागे में ज्ञान सड़ांध का एक गुच्छा है (सामान जो सच हुआ करता था और अब नहीं है)।

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

जिस्ट यह है कि अब आप राजमिस्त्री @ .com और wildwezyr@fahrvergnügen.net जैसे पतों का उपयोग कर सकते हैं। नहीं, यह अभी तक वहाँ सब कुछ के साथ संगत नहीं है (जैसा कि कई ऊपर विलाप किया है, यहां तक कि सरल qmail- शैली + पहचान पते अक्सर गलत तरीके से अस्वीकार कर दिए जाते हैं)। लेकिन एक RFC है, एक युक्ति है, यह अब IETF और ICANN द्वारा समर्थित है, और - अधिक महत्वपूर्ण बात - इस सुधार का समर्थन करने वाले कार्यान्वयन की एक बड़ी और बढ़ती संख्या है जो वर्तमान में सेवा में हैं।

मैं खुद इस विकास के बारे में ज्यादा नहीं जानता था, जब तक कि मैं जापान वापस नहीं चला गया और इस तरह से hei @ s s .ca और Amazon URL URL जैसे ईमेल पते देखने लगे:

http://www.amazon.co.jp/ エレクトロニクス - デジタルカメラ - ポータブルオーディオ / बी / ref = topnav_storetab_e यानी = UTF8 और नोड = 3,210,981

मुझे पता है कि आप चश्मे के लिंक नहीं चाहते हैं, लेकिन यदि आप इंटरनेट मंचों पर हैकर्स के पुराने ज्ञान पर पूरी तरह से भरोसा करते हैं, तो आपका ईमेल सत्यापनकर्ता उन ईमेल पतों को खारिज कर देगा जो गैर-अंग्रेजी बोलने वाले उपयोगकर्ताओं के तेजी से काम करने की उम्मीद करते हैं। उन उपयोगकर्ताओं के लिए, इस तरह की मान्यता केवल सामान्य मस्तिष्क-मृत रूप के रूप में कष्टप्रद होगी जो हम सभी से नफरत करते हैं, वह जो एक + या तीन-भाग डोमेन नाम या जो भी संभाल नहीं सकता है।

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

ऐसा करने के बाद आप ऊपर दी गई अधिकांश सलाह का पालन कर सकते हैं।

— मकान बनाने वाला
स्रोत

17

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

— मेसन

2

जावास्क्रिप्ट देवों के लिए , मैं अब इसे करने के तरीकों पर शोध कर रहा हूं, और Punycode.js सबसे पूर्ण और पॉलिश समाधान लगता है।

— wawawaw

5

ध्यान दें कि इंटरनेशनलाइज्ड ईमेल (वर्तमान में परिभाषित) गैर-ASCII पतों को पंचकोश या इसी तरह का उपयोग करके परिवर्तित नहीं करता है , इसके बजाय स्वयं SMTP प्रोटोकॉल के बड़े हिस्से को UTF8 का उपयोग करने के लिए विस्तारित करता है।

— IMSoP

2

क्या मुझे कुछ याद आ रहा है या यह सवाल का जवाब देने में विफल है? मैं पढ़ रहा हूं 'अन्य उत्तर गलत है, आपको अधिक वर्ण स्वीकार करने की आवश्यकता है' लेकिन फिर यह बताने में विफल रहता है कि कौन से अतिरिक्त वर्ण हैं। मैं भी (आसानी से) उस RFC में नहीं देख सका कि क्या इसका मतलब है कि सभी यूनिकोड कोड बिंदु या सिर्फ बीएमपी।

— शमूएल हैमर

3

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

— शॉन

59

ई-मेल पते का प्रारूप है: local-part@domain-part(अधिकतम 64 @ 255 वर्ण, कुल में कोई 256)।

local-partऔर domain-partअनुमति दी पात्रों में से अलग सेट हो सकता था, लेकिन वह सब नहीं है, वहाँ के रूप में इसे करने के लिए अधिक नियम हैं।

सामान्य तौर पर, स्थानीय भाग में ये ASCII वर्ण हो सकते हैं:

लैटिन अक्षर लोअरकेस: abcdefghijklmnopqrstuvwxyz,
लैटिन अक्षर अपरकेस: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
अंक: 0123456789,
विशेष वर्ण: !#$%&'*+-/=?^_`{|}~,
डॉट: .(पहले या अंतिम चरित्र या दोहराया नहीं जब तक उद्धृत),
अंतरिक्ष विराम चिह्न जैसे: "(),:;<>@[\](कुछ प्रतिबंधों के साथ),
टिप्पणियाँ: ()(कोष्ठक के भीतर अनुमति दी जाती है, जैसे (comment)john.smith@example.com)।

डोमेन हिस्सा:

लैटिन अक्षर लोअरकेस: abcdefghijklmnopqrstuvwxyz,
लैटिन अक्षर अपरकेस: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
अंक: 0123456789,
हाइफ़न: -(पहला या अंतिम चरित्र नहीं),
वर्गाकार कोष्ठकों से घिरा IP पता हो सकता है: jsmith@[192.168.2.1]या jsmith@[IPv6:2001:db8::1]।

ये ई-मेल पते मान्य हैं:

prettyandsimple@example.com
very.common@example.com
disposable.style.email.with+symbol@example.com
other.email-with-dash@example.com
x@example.com (एक अक्षर का स्थानीय भाग)
"much.more unusual"@example.com
"very.unusual.@.unusual.com"@example.com
"very.(),:;<>[]\".VERY.\"very@\ \"very\".unusual"@strange.example.com
example-indeed@strange-example.com
admin@mailserver1 (कोई शीर्ष-स्तरीय डोमेन के साथ स्थानीय डोमेन नाम)
#!$%&'*+-/=?^_`{}|~@example.org
"()<>[]:,;@\\"!#$%&'-/=?^_`{}| ~.a"@example.org
" "@example.org (कोट्स के बीच का स्थान)
example@localhost (लोकलहोस्ट से भेजा गया)
example@s.solutions( इंटरनेट शीर्ष-स्तरीय डोमेन की सूची देखें )
user@com
user@localserver
user@[IPv6:2001:db8::1]

और अमान्य के ये उदाहरण हैं:

Abc.example.com(कोई @चरित्र नहीं )
A@b@c@example.com( @उद्धरण चिह्नों के बाहर केवल एक की अनुमति है)
a"b(c)d,e:f;gi[j\k]l@example.com (इस स्थानीय भाग में कोई भी विशेष वर्ण उद्धरण चिह्नों के बाहर की अनुमति नहीं है)
just"not"right@example.com (उद्धृत स्ट्रिंग्स को अलग किया जाना चाहिए या केवल स्थानीय भाग बनाने वाला तत्व होना चाहिए)
this is"not\allowed@example.com (रिक्त स्थान, उद्धरण और बैकस्लैश केवल तभी मौजूद हो सकते हैं जब उद्धृत स्ट्रिंग्स के भीतर और बैकस्लैश द्वारा पूर्ववर्ती हो)
this\ still\"not\allowed@example.com (भले ही बच गए (बैकस्लैश से पहले), रिक्त स्थान, उद्धरण, और बैकस्लैश को अभी भी उद्धरण में समाहित किया जाना चाहिए)
john..doe@example.com(पहले डबल डॉट @); (कैविएट के साथ: जीमेल इसके माध्यम से अनुमति देता है)
john.doe@example..com(डबल डॉट के बाद @)
एक अग्रणी स्थान के साथ एक वैध पता
अनुगामी स्थान वाला वैध पता

स्रोत: विकिपीडिया पर ईमेल पता

ईमेल सत्यापित करने के लिए पर्ल का RFC2822 regex :

(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(
?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ 
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0
31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+
(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\
r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
 \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[
 \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+
|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t
]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031
]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?
:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?
:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?
[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|
\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>
@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"
(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?
:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[
\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-
\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(
?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;
:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([
^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\"
.\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\
]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\
[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\
r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]
|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0
00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\
.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,
;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?
:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]
]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(
?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(
?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[
\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t
])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?
:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|
\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:
[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\
]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)
?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["
()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)
?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[
 \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,
;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:
\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[
"()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])
*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])
+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\
.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(
?:\r\n)?[ \t])*))*)?;\s*)

RFC2822 पतों के लिए पूर्ण regexp केवल 3.7k था।

यह भी देखें: PHP में RFC 822 ई-मेल पता पार्सर ।

ई-मेल पते की औपचारिक परिभाषा इस प्रकार है:

RFC 5322 (अनुभाग 3.2.3 और 3.4.1, आरएससी 2822 का पालन करता है), RFC 5321, RFC 3696,
RFC 6531 (अनुमत वर्ण)।

सम्बंधित:

नियमित अभिव्यक्ति की सच्ची शक्ति

— kenorb
स्रोत

5

इस रेगेक्स के कार्यान्वयनकर्ताओं के लिए एक अतिरिक्त सावधानी के रूप में: नहीं। बस सत्यापित करें कि यह प्रारूप को बढ़ाता है something@something.somethingऔर इसे एक दिन कहता है।

— क्रिस सोबोलेवस्की

हालांकि ऐसा कुछ बनाए रखने योग्य नहीं है, यह डिकोड करने के लिए एक अच्छा व्यायाम है और वास्तव में यह पता लगाने के लिए कि यह क्या करता है

— at'१

@

— क्रिसहॉबोलेव्स्की

मैंने एक चेक_recipient_access प्रतिबंध के तहत pcre एक्सेस टेबल के माध्यम से पोस्टफिक्स में इसे लागू करने की कोशिश की है, पहले 3 लंबी पीसीआर (लिंक्ड पेज से) को एक-एक लाइन में टॉपिंग और टॉपिंग और इस तरह से सिलाई कर रहा है: $ / DUNNO, फिर एक अंतिम पंक्ति / .* / REJECT जोड़ रहा है, लेकिन यह अभी भी अमान्य ईमेल पतों के माध्यम से अनुमति देता है। उपसर्ग 3.3.0; पर्ल 5, संस्करण 26, तोड़फोड़ 1 (v5.26.1)।

— scoobydoo

3

पागलपन मैं कहता हूं। जो कभी इसका उत्पादन में उपयोग करेगा। एक ऐसा बिंदु है जहां नियमित अभिव्यक्ति का उपयोग नहीं किया जाना चाहिए। यह उस बिंदु से बहुत परे है।

— तमंचा

22

इस पर विकिपीडिया का अच्छा लेख है , और आधिकारिक युक्ति यहाँ है । विकिपीडिया से:

ई-मेल पते का स्थानीय हिस्सा इनमें से किसी भी ASCII वर्ण का उपयोग कर सकता है:

अपरकेस और अंग्रेजी अक्षरों को कम करना (az, AZ)

अंक 0 से 9

पात्र ! # $% & '* + - / =? ^ _ `{| } ~

चरित्र। (डॉट, पीरियड, फुल स्टॉप) बशर्ते कि यह पहला या आखिरी चरित्र न हो, और यह भी प्रदान किया जाए कि यह लगातार दो या दो से अधिक दिखाई न दे।

इसके अतिरिक्त, उद्धृत-स्ट्रिंग्स (यानी: "जॉन डो" @ example.com) की अनुमति दी जाती है, इस प्रकार उन पात्रों को अनुमति दी जाती है जो अन्यथा निषिद्ध होंगे, हालांकि वे आम व्यवहार में प्रकट नहीं होते हैं। RFC 5321 यह भी चेतावनी देता है कि "एक होस्ट जो मेल SHOULD प्राप्त करने की अपेक्षा करता है, मेलबॉक्सों को परिभाषित करने से बचता है जहां स्थानीय-भाग को आवश्यकता होती है (या कोटेड-स्ट्रिंग फॉर्म का उपयोग करता है")।

— माइक वेलर
स्रोत

@WildWezyr Valid hostnames, जो एक IP पता, FQN, या स्थानीय नेटवर्क होस्ट के लिए कुछ संभव हो सकता है।

— जेन्सेनडाईड

एक प्रवेश द्वार से गुजरने के लिए उद्धृत तार आवश्यक थे, बरगद की बेलें याद हैं?

— mckenzm

13

Google अपने gmail.com पते के साथ एक दिलचस्प काम करते हैं। gmail.com पते केवल अक्षरों (az), संख्याओं और अवधियों (जिन्हें अनदेखा किया जाता है) की अनुमति देते हैं।

जैसे, pikachu@gmail.com pi.kachu@gmail.com के समान है, और दोनों ईमेल पते एक ही मेलबॉक्स पर भेजे जाएंगे। PIKACHU@gmail.com भी उसी मेलबॉक्स में दिया जाता है।

तो सवाल का जवाब देने के लिए, कभी-कभी यह कार्यान्वयनकर्ता पर निर्भर करता है कि वे आरएफसी मानकों का कितना पालन करना चाहते हैं। Google की gmail.com पता शैली मानकों के अनुकूल है। वे इसे भ्रम से बचने के लिए करते हैं, जहां विभिन्न लोग समान ईमेल पते जैसे उदाहरण लेते हैं

*** gmail.com accepting rules ***
d.oy.smith@gmail.com   (accepted)
d_oy_smith@gmail.com   (bounce and account can never be created)
doysmith@gmail.com     (accepted)
D.Oy'Smith@gmail.com   (bounce and account can never be created)

विकिपीडिया लिंक एक अच्छा संदर्भ है जो आम तौर पर ईमेल पते की अनुमति देता है। http://en.wikipedia.org/wiki/Email_address

— एंजल कोह
स्रोत

2

हाँ, यह इस बारे में एक महान जवाब है कि जीमेल इसके साथ ईमेल बनाने की अनुमति क्यों नहीं देता है। लेकिन आप {john'doe}@my.serverबिना किसी समस्या के ईमेल भेज और पुन: प्राप्त कर सकते हैं । HMail सर्वर के साथ भी परीक्षण किया गया।

— पियोट कुला

आप अपने ग्राहक को एक ईमेल भेजकर परीक्षण कर सकते हैं {piotr'kula}@kula.solutions- यदि यह काम करता है तो आपको एक अच्छा ऑटो उत्तर मिलेगा। नहीं तो कुछ नहीं होगा।

— पियोट कुला

3

जीमेल RFC 6530 का अनुसरण इस अर्थ में करता है कि Gmail द्वारा अनुमत हर संभव ई-मेल पता RFC के अनुसार मान्य है। जीमेल केवल अतिरिक्त नियमों के साथ स्वीकार्य पते के सेट को और अधिक सीमित करने और स्थानीय भाग में डॉट्स के साथ अन्यथा समान पते बनाने के लिए चुनता है, वैकल्पिक रूप से "+" और अल्फ़ान्यूमेरिक वर्णों के साथ पर्यायवाची।

— तेमू लीस्टी

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

— ब्रैडकिसने79

यह सिर्फ जीमेल नहीं है, कुछ प्रदाताओं में "रिले फिल्टर" हैं जो कुछ उद्धृत स्ट्रिंग्स को अस्वीकार करते हैं, विशेष रूप से "=" जैसे कि वे सीमांकक थे। यह उपयोगकर्ताओं को निजी उद्धृत स्ट्रिंग में गेटवे और नेस्टिंग स्पैम पते सेट करने से रोकना है। "@" वैध है लेकिन "= @ =" मान्य नहीं है।

— mckenzm

12

आप विकिपीडिया लेख से शुरू कर सकते हैं :

अपरकेस और अंग्रेजी अक्षरों को कम करना (az, AZ)
अंक 0 से 9
पात्र ! # $% & '* + - / =? ^ _ `{| } ~
चरित्र। (डॉट, पीरियड, फुल स्टॉप) बशर्ते कि यह पहला या आखिरी चरित्र न हो, और यह भी प्रदान किया जाए कि यह लगातार दो या दो से अधिक दिखाई न दे।

— व्लादिमीर
स्रोत

11

नाम:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!#$%&'*+-/=?^_`{|}~.

सर्वर:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

— ThinkingStiff
स्रोत

4

के बारे में <>और क्या []? जैसे "()<>[]:,;@\\\"!#$%&'-/=?^_{} | ~ .a "@ example.org`?

— kenorb

20

कृपया सूत्रों का हवाला दें। सूत्रों के बिना, यह अनुमान जैसा लगता है।

— मैथ्यू के।

15

यह पुराना है, और संभवतः कभी सही नहीं था।

— जेसन हैरिसन

9

@ और के लिए जाँच करें। और फिर उन्हें सत्यापित करने के लिए एक ईमेल भेजें।

मैं अभी भी इंटरनेट पर 20% साइटों पर अपने .name ईमेल पते का उपयोग नहीं कर सकता क्योंकि किसी ने उनके ईमेल सत्यापन को खराब कर दिया था, या क्योंकि यह नए पते वैध होने का अनुमान लगाता है।

— रिचर्ड मैक्सवेल
स्रोत

9

यहाँ तक की । सख्ती से आवश्यक नहीं है; मैंने शीर्ष स्तर के डोमेन (विशेष रूप से ua) पर ईमेल पते के कम से कम एक मामले के बारे में सुना है। पता था <name> @ua - no dot!

यह आपके सत्यापन को गड़बड़ाने का सबसे आसान तरीका है, क्योंकि लगभग हर चीज की अनुमति है, और अगर कुछ की अनुमति नहीं है, तो प्राप्तकर्ता का सर्वर आपको बता देगा।

— अवमेंडर

5

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

आपके द्वारा बनाए गए पतों के अच्छे मार्गदर्शक के लिए; देखें: http://www.remote.org/jochen/mail/info/chars.html

मान्य ईमेल फ़िल्टर करने के लिए, बस अगले चरण को देखने के लिए पर्याप्त समझदार चीज़ पर पास करें। या आरएफसी का एक गुच्छा पढ़ना शुरू करें, सावधानी, यहां ड्रेगन हो।

— माइकल जेम्स
स्रोत

लिंक हो गया है। क्या सामग्री थी?

— 1919

5

मामले पर एक अच्छा पढ़ा ।

अंश:

These are all valid email addresses!

"Abc\@def"@example.com
"Fred Bloggs"@example.com
"Joe\\Blow"@example.com
"Abc@def"@example.com
customer/department=shipping@example.com
\$A12345@example.com
!def!xyz%abc@example.com
_somename@example.com

— ल्यूक माधंगा
स्रोत

1

मैं डोमेन भाग से पहले '@' के बारे में सोच रहा था। क्या इसका उपयोग किया जा सकता है?

— सैय्यफ फ़ारूक

@SaiyaffFarouk विनिर्देशन के अनुसार, हाँ। हालाँकि, अधिकांश मेल प्रदाताओं को इसकी संभावना के भाग के रूप में अनुमति नहीं दी जाएगी

— ल्यूक माधंगा

वह ब्लॉग Joe.\\Blow@example.comबिना उद्धरणों के सूचीबद्ध करता है। क्या यह वास्तव में वैध है? यह स्पष्ट नहीं लगता है कि यहां दिए गए उत्तर दिए गए हैं, लेकिन मैं इसलिए पूछ रहा हूं क्योंकि मैंने DNS सोअनाम ईमेल स्ट्रिंग्स के बहुत (दुर्लभ) मामलों को देखा है जिसमें बैकस्लैश शामिल हैं।

— wesinat0r

5

स्वीकृत उत्तर एक विकिपीडिया लेख को संदर्भित करता है जब एक ईमेल पते के वैध स्थानीय-भाग पर चर्चा की जाती है, लेकिन विकिपीडिया इस पर कोई अधिकार नहीं है।

IETF RFC 3696 इस मामले पर एक प्राधिकरण है, और इसे अनुभाग 3 से परामर्श किया जाना चाहिए । पृष्ठ 5 पर ईमेल पते पर प्रतिबंध :

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

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

सटीक नियम यह है कि कोई भी ASCII वर्ण, जिसमें नियंत्रण वर्ण शामिल हैं, उद्धृत किए जा सकते हैं, या उद्धृत स्ट्रिंग में हो सकते हैं। जब उद्धरण की आवश्यकता होती है, तो बैकस्लैश वर्ण का उपयोग निम्न वर्ण को उद्धृत करने के लिए किया जाता है। उदाहरण के लिए
  Abc\@def@example.com
एक ईमेल पते का एक वैध रूप है। रिक्त स्थान भी दिखाई दे सकते हैं, जैसे कि
  Fred\ Bloggs@example.com
बैकस्लैश चरित्र का उपयोग स्वयं को उद्धृत करने के लिए भी किया जा सकता है, जैसे,
  Joe.\\Blow@example.com
बैकस्लैश कैरेक्टर का उपयोग करते हुए उद्धृत करने के अलावा, स्ट्रिंग्स को घेरने के लिए पारंपरिक डबल-कोट कैरेक्टर का उपयोग किया जा सकता है। उदाहरण के लिए
  "Abc@def"@example.com

  "Fred Bloggs"@example.com
ऊपर के पहले दो उदाहरणों के वैकल्पिक रूप हैं। इन उद्धृत रूपों की शायद ही कभी सिफारिश की जाती है, और अभ्यास में असामान्य हैं, लेकिन, जैसा कि ऊपर चर्चा की गई है, उन अनुप्रयोगों द्वारा समर्थित होना चाहिए जो ईमेल पते को संसाधित कर रहे हैं। विशेष रूप से, उद्धृत रूप अक्सर अन्य प्रणालियों और संदर्भों से संक्रमण से जुड़े पतों के संदर्भ में प्रकट होते हैं; वे संक्रमणकालीन आवश्यकताएं अभी भी उत्पन्न होती हैं और, चूंकि एक सिस्टम जो उपयोगकर्ता द्वारा प्रदान किए गए ईमेल पते को स्वीकार करता है, वह "पता" नहीं कर सकता है कि क्या यह पता एक विरासत प्रणाली से जुड़ा हुआ है, पते के रूपों को स्वीकार किया जाना चाहिए और ईमेल वातावरण में पारित किया जाना चाहिए।

उद्धरण के बिना, स्थानीय-भागों में
वर्णों के किसी भी संयोजन , अंक या विशेष वर्णों में से कोई भी हो सकता है
  ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~
अवधि ("।") भी दिखाई दे सकती है, लेकिन इसका उपयोग स्थानीय भाग को शुरू करने या समाप्त करने के लिए नहीं किया जा सकता है, न ही दो या अधिक लगातार अवधि दिखाई दे सकती है। भिन्न रूप से, किसी भी ASCII ग्राफिक (मुद्रण) के अलावा एट-साइन ("@") वर्ण, बैकस्लैश, दोहरे उद्धरण, अल्पविराम या वर्ग कोष्ठक उद्धृत किए बिना प्रकट हो सकते हैं। यदि बहिष्कृत पात्रों की सूची में से कोई भी प्रकट होना है, तो उन्हें उद्धृत किया जाना चाहिए। जैसे फार्म
  user+mailbox@example.com

  customer/department=shipping@example.com

  $A12345@example.com

  !def!xyz%abc@example.com

  _somename@example.com
मान्य हैं और काफी नियमित रूप से देखे जाते हैं, लेकिन ऊपर सूचीबद्ध किसी भी वर्ण की अनुमति है।

जैसा कि अन्य लोगों ने किया है, मैं ईमेल पते को मान्य करने के लिए PHP और जावास्क्रिप्ट दोनों के लिए काम करने वाला एक rexx प्रस्तुत करता हूं:

/^[a-z0-9!'#$%&*+\/=?^_`{|}~-]+(?:\.[a-z0-9!'#$%&*+\/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-zA-Z]{2,}$/i

— मैक
स्रोत

3

जैसा कि इस विकिपीडिया लिंक में पाया जा सकता है

ईमेल पते का स्थानीय हिस्सा इनमें से किसी भी ASCII वर्ण का उपयोग कर सकता है:

अपरकेस और लैटिन पत्र लोअरकेस Aकरने के लिए Zऔर aकरने के लिए z;

अंकों 0को 9;

विशेष वर्ण !#$%&'*+-/=?^_`{|}~;

डॉट ., बशर्ते कि यह उद्धृत किए बिना पहला या अंतिम चरित्र नहीं है, और यह भी प्रदान किया जाता है कि यह लगातार प्रकट नहीं होता है जब तक कि उद्धृत नहीं किया जाता है (उदाहरण John..Doe@example.comकी अनुमति नहीं है लेकिन "John..Doe"@example.comअनुमति दी गई है);

अंतरिक्ष और "(),:;<>@[\]पात्रों को प्रतिबंध के साथ अनुमति दी जाती है (उन्हें केवल एक उद्धृत स्ट्रिंग के अंदर अनुमति दी जाती है, जैसा कि नीचे दिए गए पैराग्राफ में वर्णित है, और इसके अलावा, बैकस्लैश या दोहरे-उद्धरण को बैकस्लैश से पहले होना चाहिए);

स्थानीय-भाग के किसी भी छोर पर कोष्ठक के साथ टिप्पणियों की अनुमति है; जैसे john.smith(comment)@example.comऔर (comment)john.smith@example.comदोनों के बराबर हैं john.smith@example.com।

उपरोक्त ASCII वर्णों के अलावा, U + 007F से ऊपर के अंतर्राष्ट्रीय वर्ण, UTF-8 के रूप में एन्कोड किए गए, RFC 6531 द्वारा अनुमति दी जाती है , हालांकि मेल सिस्टम स्थानीय वर्णों को निर्दिष्ट करते समय किस वर्ण का उपयोग करने के लिए प्रतिबंधित कर सकता है।

एक उद्धृत स्ट्रिंग स्थानीय-भाग के भीतर एक बिंदीदार निकाय के रूप में मौजूद हो सकती है, या यह तब मौजूद हो सकती है जब सबसे बाहरी उद्धरण स्थानीय-भाग के सबसे बाहरी वर्ण होते हैं (उदाहरण के लिए, abc."defghi".xyz@example.comया "abcdefghixyz"@example.comअनुमति दी जाती है। इसके विपरीत, abc"defghi"xyz@example.comऐसा नहीं है; और न ही abc\"def\"ghi@example.com)। उद्धृत स्ट्रिंग्स और वर्ण हालांकि, आमतौर पर उपयोग नहीं किए जाते हैं। RFC 5321 यह भी चेतावनी देता है कि "एक होस्ट जो मेल SHOULD प्राप्त करने की अपेक्षा करता है, मेलबॉक्सों को परिभाषित करने से बचता है जहां स्थानीय-भाग के लिए (या कोटेड-स्ट्रिंग फॉर्म की आवश्यकता होती है)"।

स्थानीय-भाग postmasterको विशेष रूप से व्यवहार किया जाता है - यह स्थिति-असंवेदनशील है, और इसे डोमेन ईमेल व्यवस्थापक को भेजा जाना चाहिए। तकनीकी तौर पर अन्य सभी स्थानीय भागों केस-संवेदी होते हैं, इसलिए jsmith@example.comऔर JSmith@example.comअलग मेलबॉक्स निर्दिष्ट; हालाँकि, कई संगठन अपरकेस और लोअरकेस अक्षरों को समान मानते हैं।

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

— यश पटेल
स्रोत

0

उत्तर है (लगभग) ALL(7-बिट ASCII)।
यदि समावेशन नियम "... कुछ / किसी भी / कोई भी शर्तों के तहत अनुमत ..."

आरएफसी 5322 में "डोमेन टेक्स्ट" भाग में अनुमत पाठ के लिए कई संभावित समावेश नियमों में से एक को देखकर, हम 17 पृष्ठ के शीर्ष पर हैं:

dtext          =   %d33-90 /          ; Printable US-ASCII
                   %d94-126 /         ;  characters not including
                   obs-dtext          ;  "[", "]", or "\"

इस विवरण में केवल तीन लापता चार्ट का उपयोग डोमेन-शाब्दिक में [], उद्धृत-जोड़ी बनाने के लिए \, और श्वेत स्थान वर्ण (% d32) में किया जाता है। इसके साथ पूरी रेंज 32-126 (दशमलव) का उपयोग किया जाता है। एक समान आवश्यकता "क्यूटेक्स्ट" और "कॉटेक्स" के रूप में दिखाई देती है। कई नियंत्रण पात्रों को भी अनुमति / उपयोग किया जाता है। इस तरह के नियंत्रण वर्णों की एक सूची RFC 5322 के पृष्ठ 31 सेक्शन 4.1 में नो-डब्लूएस-डब्ल्यूएस-सीटीएल के रूप में दिखाई देती है।

obs-NO-WS-CTL  =   %d1-8 /            ; US-ASCII control
                   %d11 /             ;  characters that do not
                   %d12 /             ;  include the carriage
                   %d14-31 /          ;  return, line feed, and
                   %d127              ;  white space characters

यह सभी नियंत्रण वर्ण खंड 3.5 की शुरुआत में बताए गए हैं:

.... MAY be used, the use of US-ASCII control characters (values
     1 through 8, 11, 12, and 14 through 31) is discouraged ....

और ऐसा समावेश नियम "इसलिए बहुत व्यापक" है। या, दूसरे अर्थ में, अपेक्षित नियम "बहुत सरल" है।

0

सादगी की खातिर, मैं दोहरे उद्धरण के भीतर सभी पाठों को हटाने और सत्यापन से पहले आसपास के दोहरे उद्धरणों से जुड़े लोगों को प्रस्तुत करने से रोक देता हूं, किबोश को ईमेल पते पर प्रस्तुतियाँ डाल दी जाती हैं जो कि अस्वीकृत हैं। सिर्फ इसलिए कि किसी के पास जॉन हो सकता है .. "* $ hizzle * Bizzle" .. Doe@whatever.com पता का मतलब यह नहीं है कि मुझे इसे अपने सिस्टम में अनुमति देनी होगी। हम भविष्य में रह रहे हैं जहां आपके बट को पोंछते हुए एक अच्छा काम करने की तुलना में मुफ्त ईमेल पते को प्राप्त करने में शायद कम समय लगता है। और ऐसा नहीं है कि ईमेल मानदंड यह कहते हुए इनपुट के ठीक बगल में नहीं गिराया गया है और इसकी अनुमति नहीं है।

मैं उद्धृत सामग्री को हटा दिए जाने के बाद विभिन्न RFC द्वारा विशेष रूप से अनुमति नहीं दी जाती है। विशेष रूप से अस्वीकृत वर्ण और पैटर्न की सूची परीक्षण के लिए बहुत छोटी सूची लगती है।

अनुमति न दिया:

    local part starts with a period ( .account@host.com )
    local part ends with a period   ( account.@host.com )
    two or more periods in series   ( lots..of...dots@host.com )
    &’`*|/                          ( some&thing`bad@host.com )
    more than one @                 ( which@one@host.com )
    :%                              ( mo:characters%mo:problems@host.com )

दिए गए उदाहरण में:

John.."The*$hizzle*Bizzle"..Doe@whatever.com --> John..Doe@whatever.com

John..Doe@whatever.com --> John.Doe@whatever.com

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

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

मैं अपने सिस्टम पर स्टिंकहोल ईमेल की अनुमति नहीं देता, हो सकता है कि वह सिर्फ पैसे फेंक रहा हो। लेकिन, ९९.९% लोग बस सही काम करते हैं और एक ऐसा ईमेल होता है जो किनारे मामले की अनुकूलता परिदृश्यों का उपयोग करने के लिए कगार की सीमा को धक्का नहीं देता है। रेगेक्स DDoS से सावधान रहें, यह एक ऐसी जगह है जहाँ आप मुसीबत में पड़ सकते हैं। और यह तीसरी चीज से संबंधित है जो मैं करता हूं, मैंने इस पर एक सीमा लगा दी है कि मैं कितने समय तक किसी एक ईमेल को संसाधित करने के लिए तैयार हूं। यदि इसे मान्य करने के लिए मेरी मशीन को धीमा करने की आवश्यकता है - तो यह मेरे आने वाले डेटा एपीआई एंडपॉइंट तर्क को अतीत नहीं कर रहा है।

संपादित करें: यह उत्तर "खराब" होने के लिए रखा गया था, और शायद यह इसके योग्य था। शायद यह अभी भी बुरा है, शायद नहीं।

— BradChesney79
स्रोत

2

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

— vcarel

2

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

— होल्डऑफ ह्यूंगर

@vcarel - ओह, बिल्कुल। फ्रंट-एंड उपयोगकर्ता पक्ष सत्यापन उन्हें सूचित करेगा कि वे कौन से नियम (टूलटिप से उपलब्ध) तोड़ रहे थे। आप सही हैं- यह एक समग्र राय है। हालाँकि, उपरोक्त प्रश्न किसी ऐसे व्यक्ति से है जो X को निश्चित रूप से Y प्रश्न पूछ रहा है। यह मार्गदर्शन है और यह काम करता है ... न केवल यह काम करता है, यह अच्छी तरह से काम करता है। मैं अपने सिस्टम में जहां मैं निर्णय लेता हूं, वहां बकवास ईमेल पते नहीं होने देता।

— ब्रैडकिसने79

@HoldOffHunger मैं देख सकता हूं कि समग्र विचार उतना सुसंगत रूप से व्यक्त नहीं किया गया है जितना हो सकता है, मैं एक और दिन संशोधित कर सकता हूं जहां मेरे पास बेहतर व्यक्त करने के लिए अधिक समय है। अंतर्दृष्टि के लिए धन्यवाद।

— ब्रैडकिसने79

-1

अपने PHP में मैं इस चेक का उपयोग करता हूं

<?php
if (preg_match(
'/^(?:[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+\.)*[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+@(?:(?:(?:[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!\.)){0,61}[a-zA-Z0-9_-]?\.)+[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!$)){0,61}[a-zA-Z0-9_]?)|(?:\[(?:(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\.){3}(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\]))$/',
"tim'qqq@gmail.com"        
)){
    echo "legit email";
} else {
    echo "NOT legit email";
}
?>

इसे स्वयं आज़माएं http://phpfiddle.org/main/code/9av6-d10r

— येवगेनी अफनासयेव
स्रोत

-1

मैंने RFC के दिशानिर्देशों के अनुसार इस रेगेक्स को बनाया:

^[\\w\\.\\!_\\%#\\$\\&\\'=\\?\\*\\+\\-\\/\\^\\`\\{\\|\\}\\~]+@(?:\\w+\\.(?:\\w+\\-?)*)+$

— मऊ
स्रोत

1

यह संस्करण डोमेन / उपडोमेन की लंबाई की जाँच करके रेगेक्स को बेहतर बनाता है। का आनंद लें! ^ [\\ w \\ \\ _ \\% # \\ $ \\ & \\ '= \\ \ * \\ + \\ -।!? \\ / \\ ^ \ `\\ {\\ ???। | \\} \\ ~] @ ([\\ w] ([\\ w \\ -] {0,61} [\\ w]) (: \\ [\\ w] ((?: [\\ w \\ -] {0,61} [\\ w]])?) *) $

— Mau

-2

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

— मुहम्मद
स्रोत