कभी भी RFC ईमेल पते की पुष्टि न करें

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

हाँ, कोई बात नहीं!

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

ऐसा क्यों? मेल एड्रेस बनाने के कई तरीके हैं जो सही और भ्रम दोनों होंगे। यह आंशिक रूप से इस तथ्य के कारण है कि पिछड़े संगतता के लिए कुछ मेल सेवाएं, आपको उन स्वरूपों में पते प्रस्तुत करने की अनुमति देती हैं जो लंबे समय से पुराने हैं। उदाहरण के लिए, यह एक ईमेल है जो DNS के आगमन से पहले और आधुनिक user@domain.tld प्रारूप के आगमन से पहले मौजूद था: तब UUCP " बैंग पाथ " का उपयोग किया गया था - पते जो डिलीवरी के लिए जिम्मेदार मार्ग के साथ सभी नोड्स की एक सूची का प्रतिनिधित्व करते थे।

ईमेल पता

ईमेल पता इस तरह दिखता है:

mailbox@hostname
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

यहां, मेलबॉक्स एक स्थानीय उपयोगकर्ता खाता, एक भूमिका खाता या एक स्वचालित सिस्टम राउटर, जैसे मेलिंग सूची, और किसी भी होस्ट को होस्टनाम के रूप में इस्तेमाल किया जा सकता है यदि यह DNS सर्वर को पता है कि मेलर डिलीवरी पर पहुंचता है।

इसके अलावा, कुछ सिस्टम आपको एक पते पर टैग जोड़ने की अनुमति देते हैं। यह आमतौर पर प्रारूप में होता है:

 mailbox+tag@hostname
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

इसलिए, "मेलबॉक्स @ होस्टनाम" प्रारूप में एक पते में, "मेलबॉक्स" एक उपयोगकर्ता खाता, एप्लिकेशन या एक सिस्टम रोल खाता है, लेकिन इसमें असाधारण चीजें भी हो सकती हैं, जैसे कि छंटनी, स्वचालन या ट्रैकिंग के लिए उपयोग किए जाने वाले मार्ग या पहचानकर्ता के लिए जानकारी और "। hostname ”- आमतौर पर एक डोमेन नाम है, लेकिन यह एक उपडोमेन, सर्वर, सेवा, आईपी-पता या सिर्फ एक होस्ट नाम हो सकता है।

मान्य आरएफसी बॉक्स नाम

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

एक बॉक्स में स्थान हो सकता है। जहाँ तक मुझे याद है, प्री-इंटरनेट AOL ने "Imya Polzovatelya" में रिक्त स्थान की अनुमति दी थी, जिनका उपयोग मेलबॉक्सों के रूप में भी किया गया था, जहाँ से रिक्त स्थान काटे गए थे: "imyapolzovatelya@aol.com", हालाँकि RFC के अनुसार आप रिक्त स्थान वाले मेलबॉक्सों के दोहरे उद्धरण चिह्नों का उपयोग कर सकते हैं:

 "Alan Turing"@example.com <==  ,    
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

वैसे, इस तर्क से, केवल स्थान वाला एक बॉक्स सही है:

 " "@example.com <==  ,   
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

और यहाँ एक और मान्य पता है, यह पते के लिए मान्य वर्णों से बनाया गया है:

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

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

वैसे, एपोस्ट्रोफी की जांच करें, एपोस्ट्रोफ का समर्थन किया जाना चाहिए:

 Miles.O'Brian@example.com <==  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Apostrophes को उद्धृत या बच नहीं जाना चाहिए, लेकिन जब आप डेटाबेस को ऐसे पते सहेजते हैं या कहीं और स्थानांतरित करते हैं, तो सुनिश्चित करें कि सभी chiki-farts ।

विकिपीडिया पर कई और उदाहरण हैं।

क्या आपको पूर्ण RFC संगतता की आवश्यकता है? यह आपको चुनना है, लेकिन मैं सलाह नहीं देता - पते में रिक्त स्थान और गैर-मानक वर्ण एक असामान्य बात है और अक्सर वे केवल एक टाइपो होते हैं। बड़े ई-मेल प्रदाता लगभग समान कारणों से इसकी अनुमति नहीं देते हैं; इस प्रकार, यह आमतौर पर पत्र, संख्या, अवधि, अंडरस्कोर, हाइफ़न, एपोस्ट्रोफ़ और प्लसस की अनुमति देने के लिए पर्याप्त है।

केस संवेदनशील पते

RFC के अनुसार, एक पते की विशिष्टता उसके केस-संवेदी विशिष्टता द्वारा निर्धारित की जाती है, हालांकि, 99.9% प्रदाता अलग तरह से सोचते हैं और यदि vasyapetrov@example.com पहले से पंजीकृत है, तो VasyaPetrov@example.com को पंजीकृत न होने दें। मेलबॉक्स नाम पर विचार करें स्थिति असंवेदनशील है:

 ALLEN@example.com Allen@example.com allen@example.com
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

कुछ मुट्ठी भर सिस्टम पूरे मामले की जाँच का उपयोग करते हैं, केवल पते Allen@example.com और अन्य सभी AlleNoBs के आने वाले पत्राचार को छोड़ने की अनुमति देते हैं, लेकिन यह व्यवहार में काम नहीं करता है, क्योंकि उपयोगकर्ता का उपयोग मेल पते में मामले को अलग करने के लिए नहीं किया जाता है।

क्या आपको यहां RFC अनुकूलता रखनी चाहिए? सहेजने से पहले निचले मामलों में पते परिवर्तित करके, आप कम संख्या में उपयोगकर्ताओं (आप उन्हें पत्र नहीं भेज सकते हैं) के लिए समस्या पैदा कर सकते हैं, लेकिन मैंने कुछ ही बार लाखों ई-मेल भेजे।

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

कस्टम वर्ण

जीमेल यहां अलग है: जबकि मानक में एक मानक चरित्र के रूप में एक डॉट शामिल है, जीमेल डॉट्स के साथ या बिना मेलबॉक्स के पते के बीच अंतर नहीं करता है। ये पते उसी मेलबॉक्स की ओर इशारा करते हैं:

 first.last@gmail.com firstlast@gmail.com firstlast@gmail.com
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

कृपया ध्यान दें कि Google Apps आपको किसी भी डोमेन पर Gmail का उपयोग करने की अनुमति देता है।

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

टैग का उपयोग करके बक्से के नाम के लिए एक विस्तारित रूप।

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

 allen+one@example.com allen+two@example.com
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

लेकिन क्या मुझे मेलबॉक्स पते से टैग साफ़ करने की आवश्यकता है?

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

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

यूनिकोड और अंतर्राष्ट्रीयकृत बॉक्स नाम

बॉक्स नाम विस्तारित ASCII वर्णों (8-बिट) और यूनिकोड वर्णों का समर्थन नहीं करते हैं। यह सीमा SMTP विनिर्देश में निहित है, जिसकी उपस्थिति के समय यह सब बस अस्तित्व में नहीं था; हालाँकि, 8-बिट मान को स्थानीय रूप से परिभाषित किया गया है, उदाहरण के लिए ISO-8859-x परिवार के एन्कोडिंग से, अभी भी उपयोग किया जा सकता है, लेकिन आप अभी भी कभी नहीं जान पाएंगे कि यह किस तरह का एन्कोडिंग है। वास्तव में, मैंने केवल स्पैमर्स के साथ 8-बिट मेलबॉक्स देखे।

आखिरकार, आप अपना डेटा UTF-8 में जमा कर रहे हैं, है ना? इसलिए, किसी भी स्थिति में, आप उन्हें उस स्थान पर वापस स्थानांतरित नहीं कर सकते हैं जिसका उपयोग आपको पता नहीं था।

डोमेन नाम

मेल डोमेन की HTTP में समान सीमाएँ हैं: वे केस-असंवेदनशील हैं, इसलिए उन्हें लोअरकेस में सामान्य किया जाना चाहिए।

उप डोमेन

कुछ पतों में अनावश्यक उप-डोमेन होते हैं: उदाहरण के लिए, "email.msn.com" और "msn.com" एक ही मेल डोमेन हैं, इसके अलावा, ऐसी कहानियां अक्सर कॉर्पोरेट वातावरण में होती हैं (और यह विहितकरण के लिए एक और अच्छा उम्मीदवार है)।

अंतर्राष्ट्रीय डोमेन ( IDN )

IDN को डोमेन नाम में स्थानीय यूनिकोड वर्ण का उपयोग करने के लिए बनाया गया था, इसके अलावा, विशेष डोमेन के साथ एक डोमेन बनाना संभव है:

 postmaster@→→→→→→→.ws
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

यह प्रकृति में पानी के चक्र का वर्णन करता है।

HTTP की तरह, SMTP केवल 7-बिट एन्कोडिंग का समर्थन करता है, और इस दुर्भाग्य से निपटने के लिए , IDNs को Punycode में परिवर्तित किया जाता है, जो डोमेन नाम को यूनिकोड से परिवर्तित करने की अनुमति देता है:

 postmaster@xn--55gaaaaaa281gfaqg86dja792anqa.ws
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

इससे कई सवाल उठते हैं जिनका जवाब दिया जाना चाहिए:

क्या हमें IDN पतों की अनुमति देनी चाहिए? क्या हम एक समर्थन सेवा के साथ उपयोगकर्ताओं के लिए समर्थन प्रदान कर सकते हैं (जहां समर्थन, उदाहरण के लिए, चीनी वर्णों के साथ कीबोर्ड हैं?) क्या हमें उन्हें यूनिकोड या पुनीकोड ​​में संग्रहीत करना चाहिए? यदि हम विहित पते रखते हैं, तो यह किस कूटबन्धन में है? क्या हमारा मेलर (MTA) सामान्य रूप से IDN का समर्थन करता है, और पत्र भेजते समय वह किस रूप में एक पते की प्रतीक्षा करता है?

आईपी ​​एड्रेस सिंटैक्स

IP पते का उपयोग करने की अनुमति है:

 allen@[127.0.0.1] allen@[IPv6:0:0:1]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

हालांकि, ऐसे पते संदिग्ध लगते हैं, और यह संभावना नहीं है कि उन पर भरोसा किया जाना चाहिए।

अस्थायी डाक पते

ऐसी कई सेवाएं हैं जो उपयोगकर्ताओं को अस्थायी डाक पते प्रदान करती हैं। यह आमतौर पर गुमनामी के लिए या अविश्वसनीय साइटों पर पंजीकरण के लिए उपयोग किया जाता है।

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

सफेद सूची सुविधाएँ

ईमेल पते राक्षसी रूप से जटिल हो सकते हैं, लेकिन, वैसे, 99.99% (या शायद अधिक) सरल सिद्धांतों का पालन करते हैं, और बाकी बनाए रखने के लिए बहुत थकाऊ हैं।

इसलिए, यदि आपको इसमें पता होना चाहिए, तो आपको पते का समर्थन करने से बचना चाहिए:

• मामला संवेदनशील
• अंतराल
• उद्धरण चिह्न या भागने के पात्र
• '._+-
  
  
  
  अलावा अन्य विशेष वर्ण
• डोमेन फ़ील्ड में IP
• IDN

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

मेरा यह भी मानना ​​है कि आपको टैग का समर्थन करना चाहिए।

यदि आवश्यक हो, तो आप डेटाबेस में विहित पते के साथ एक और क्षेत्र बना सकते हैं, भले ही आपको लगता है कि यह सभी RFC संगतता का समर्थन किया जाना चाहिए। इस क्षेत्र का पता निम्न हो सकता है:

• छोटे अक्षरों में दिखाया गया है
• बिना टैग के हो
• यूनिकोड से एएससीआईआई तक ट्रांसकोड किया गया
• कोई डुप्लिकेट उप डोमेन नहीं

इस तथ्य के बावजूद कि यह सलाह बहुत अधिक कट्टरपंथी लग सकती है, यह अभी भी आँख बंद करके मानकों का पालन करने से बेहतर है। कौन जानता है, शायद किसी दिन ऐसा सरलीकृत अंकन एक नया मानक बन जाएगा?