ईमेल पता सिंटैक्स सीमाएं: क्या मान्य है और क्या नहीं

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

एट चिह्न के दोनों ओर के दो हिस्से

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

डोमेन वह हिस्सा है जिसे पूरे मेल सिस्टम को ढूंढ़ पाना होता है, इसलिए उस पर मेल के नियम नहीं, डोमेन के नियम लागू होते हैं। संदेश भेजते समय भेजने वाली तरफ़ डोमेन देखकर वह सर्वर ढूंढ़ती है जो उसके लिए मेल लेता है, और फिर संदेश उसी सर्वर को सौंपा जाता है। बिना ऐसी रिकॉर्ड प्रविष्टि के जो पाने वाले सर्वर का नाम बताए, संदेश के जाने की कोई जगह नहीं होती।

यही बंटवारा व्यवहारिक सलाह की शुरुआत भी है: डोमेन की जांच सख़्ती से कीजिए, क्योंकि यहां ग़लती का मतलब है ऐसी मेल जो कभी पहुंच ही नहीं सकती; और लोकल पार्ट के साथ नरमी रखिए, क्योंकि वहां सख़्ती सिर्फ़ उन पतों को ठुकराती है जो चल जाते।

पता कितना लंबा हो सकता है?

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

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

फ़ॉर्म या तालिका बनाने वाले के लिए सबक़ यह है कि फ़ील्ड मानक के हिसाब से नापें और जो बाइटें असल में मिली हों उन्हें वैसी ही रखें। किसी पते को चुपचाप काट देना उसे ठुकराने से बुरा है, क्योंकि जो अकाउंट बन जाता है, उसे कुछ भी कभी नहीं पहुंच सकता।

मानक क्या अनुमति देता है पर ज़्यादातर सेवाएं ठुकरा देती हैं

यह ढांचा उस मेल से कहीं ज़्यादा उदार है जो ज़्यादातर लोगों को मिलती है। मानक जिन शक्लों की अनुमति देता है उनमें शामिल हैं: कोटेशन चिह्नों के भीतर लिखा लोकल पार्ट, कोष्ठक में टिप्पणियां, डोमेन का नाम के बजाय कोष्ठक में लिखा पता, और अंतरराष्ट्रीयकरण के विस्तारों के तहत किसी भी हिस्से में गैर-ASCII अक्षर।

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

अपने कोड में ले जाने लायक नतीजा साफ़ है: ढांचे की जांच दुनिया के बारे में कोई बयान नहीं है। उसका पास होना बस इतना बताता है कि पता ठीक बना हुआ है। इससे यह नहीं निकलता कि कोई सेवा उसे स्वीकार करेगी, और यह भी नहीं कि उसके पीछे कोई अकाउंट मौजूद है।

मान्य पता फिर भी ठुकराया क्यों जाता है?

तीन वजहें हैं, और उनमें से कोई भी ढांचे से जुड़ी नहीं।

पहली यह कि वह डोमेन मेल लेता ही न हो। ऐसे डोमेन पर ढांचे की दृष्टि से बेदाग़ पता, जिसका कोई पाने वाला सर्वर ही नहीं या जो हर मेल ठुकरा देता है, कभी नहीं पहुंच सकता। यही वह मामला है जिससे बचने के लिए फेंकने वाला इनबॉक्स बनाया जाता है: टेम्प मेल टूल आपको ऐसे डोमेन पर पता देता है जो उसी समय मेल ले रहा है, इसलिए पहुंचने का रास्ता वह हिस्सा है जिसे आपको जुटाना नहीं पड़ता।

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

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

ऐसे पते बनाना जिन्हें सेवाएं स्वीकार करें

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

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

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

डेवलपर्स के लिए: सत्यापन, फ़ील्ड की चौड़ाई और केस

तीन आदतें पता संभालने की ज़्यादातर ख़ामियां रोक देती हैं।

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

भंडारण मानक के हिसाब से नापिए। लोकल पार्ट को 64 बाइट की जगह दीजिए, डोमेन को 255 की, और पूरे ख़ाने को विराम-चिह्नों समेत 256 की। सीमा को जानबूझकर आज़माइए, एक लंबे लोकल पार्ट के साथ, क्योंकि ज़रूरत से लंबा इनपुट ही वह मामला है जो चुपचाप काट दिया जाता है।

सामान्यीकरण जानबूझकर कीजिए, और यह लिखकर रखिए कि क्या सामान्यीकृत किया जा रहा है। ख़ाली जगह हटाना और डोमेन को छोटे अक्षरों में लाना निरापद और अपेक्षित है। लोकल पार्ट को छोटे अक्षरों में लाना प्रचलित है पर तकनीकी रूप से पते में बदलाव है, इसलिए उसे ऐसा फ़ैसला बनाइए जिसकी ओर आप उंगली उठा सकें, किसी सहायक फ़ंक्शन का इत्तेफ़ाक़ नहीं।

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

अगले क़दम

अपने प्रोडक्ट में पते वाला ख़ाना लेकर ऊपर की तालिका से नापिए; अगर वह मानक के बजाय रीति पर नापा गया है, तो उसे चौड़ा कीजिए इससे पहले कि किसी का पता साइनअप के समय कट जाए। फिर टेम्प मेल पेज खोलिए और उस उबाऊ शक्ल में एक पता बनाइए, ताकि आप देख सकें कि आपका सत्यापनकर्ता ऐसे इनपुट के साथ क्या करता है जिसे स्वीकार करना निर्विवाद है।