टेस्ट के लिए फ़ेक ईमेल: रजिस्ट्रेशन फ़ॉर्म के लिए सुरक्षित पते
अगर आप वेबसाइट बनाते या जाँचते हैं, तो आप लगातार फ़ॉर्म में ईमेल पते लिखते रहते हैं। एक चीज़ कभी नहीं होनी चाहिए: टेस्ट मेल किसी अनजान इंसान के असली मेलबॉक्स में पहुँच जाए। यह पेज बताता है कि किस तरह की जाँच के लिए कौन-सा फ़ेक ईमेल लें — और कब मेल का सचमुच पहुँचना ज़रूरी है।
पहले तय कीजिए: क्या ईमेल पहुँचनी चाहिए?
यही एक सवाल सब कुछ तय करता है, और इसे साफ़ पूछना चाहिए, क्योंकि जवाब “नहीं” लोगों की सोच से कहीं ज़्यादा बार होता है।
| आप क्या जाँच रहे हैं | मेल पहुँचनी चाहिए? | क्या इस्तेमाल करें |
|---|---|---|
| पते की वैलिडेशन, सेव होना या दिखना | नहीं | आरक्षित डोमेन — नीचे देखिए |
| कन्फ़र्मेशन का पूरा क्रम, हाथ से | हाँ | यहाँ का मेलबॉक्स |
| कन्फ़र्मेशन का पूरा क्रम, अपने आप | हाँ, कोड से पढ़ी जा सके | API वाली सेवा |
| लोड या ज़्यादा मात्रा की जाँच | नहीं — और पहुँचनी भी नहीं चाहिए | हमेशा आरक्षित डोमेन |
जब मेल नहीं पहुँचनी चाहिए: आरक्षित नाम लीजिए
कुछ डोमेन ठीक इसी काम के लिए बने हैं और यह पक्का है कि वे कभी किसी के नहीं होंगे: example.com और उसके साथी example.net और example.org, जिन्हें RFC 2606 ने आरक्षित किया है, और साथ में पूरा .test ज़ोन।
इन डोमेन पर बने पते नमूना डेटा, शुरुआती डेटा और लोड टेस्ट के लिए सही जवाब हैं। आप जो भी भेजें, वह किसी इंसान तक नहीं पहुँच सकता, क्योंकि वहाँ कोई है ही नहीं — यह अंतरराष्ट्रीय समझौते से तय है, क़िस्मत से नहीं।
test@mycompanytest.com अक्सर किसी का असली डोमेन निकलता है, और उस पर भेजा गया लोड टेस्ट हमले से अलग नहीं दिखता। आरक्षित नाम मुफ़्त हैं और इस तरह की पूरी दुर्घटना ही ख़त्म कर देते हैं।जब मेल पहुँचनी चाहिए, हाथ से जाँच
यहाँ से पता लीजिए, पूरा क्रम चलाइए, और पढ़िए कि आपका ऐप्लिकेशन असल में क्या भेजता है — हेडर, लिंक, और मेल कैसी दिखती है जब उसे आपका अपना मेल प्रोग्राम नहीं दिखा रहा। इस तरह दो चीज़ें पकड़ में आती हैं, जो लोकल मेल पकड़ने वाला औज़ार नहीं पकड़ता:
- असली डिलीवरी। मेल असली ईमेल रास्ते से गुज़रती है, इसलिए ग़लत सेटिंग वाला भेजने वाला यहीं फ़ेल होता है, प्रोडक्शन में नहीं।
- किसी अनजान की नज़र से मेल कैसी दिखती है। ऐसे लिंक जो सिर्फ़ आपके सेशन में चलते हैं, तस्वीरें जो कभी लोड नहीं होतीं, अनसब्सक्राइब लिंक जो localhost पर ले जाता है — सब तुरंत दिख जाता है।
अगर आपका ऐप्लिकेशन फ़ाइलें भेजता है, तो अटैचमेंट की चेतावनी पर भी ध्यान दीजिए: आपके यूज़र्स को यही चेतावनी दिखेगी।
जब यह अपने आप होना चाहिए
इसकी जगह पेज को स्क्रैप करना बुरा सौदा है, भले ही चल जाए: नाज़ुक, बिना दस्तावेज़ के, और ठीक उसी तरह का ट्रैफ़िक जो आख़िर में ब्लॉक हो जाता है।
ठुकराए जाने वाले रास्तों की जाँच
दिलचस्प नाकामी “सही पता चल जाता है” नहीं है। जाँचने लायक़ चीज़ें ये हैं:
- ऐसे डोमेन पर पता जिसका MX रिकॉर्ड नहीं है — पता सही लिखा है, फिर भी डिलीवरी फ़ेल होती है। आपका कोड इन दोनों में फ़र्क़ कर पाए, यह अच्छा है। कौन-सा कौन है, जाँचिए।
- अंतरराष्ट्रीय डोमेन, यूनिकोड और
xn--दोनों रूपों में। ज़्यादातर वैलिडेटर एक को ठुकराते हैं और दूसरे को मानते हैं, और अक्सर उल्टा — कन्वर्टर। - बिंदु और प्लस वाले Gmail के रूप। अगर आपकी “पहले से है या नहीं” वाली जाँच सीधा टेक्स्ट मिलाती है, तो एक व्यक्ति अनगिनत खाते बना सकता है। पहले उन्हें एक रूप में लाइए — वह पेज ठीक वही करता है जो आपकी जाँच को करना चाहिए।
- बहुत लंबा नाम (
@से पहले वाला हिस्सा)। मानक 64 अक्षर तक की इजाज़त देता है; कई फ़ॉर्म चुपचाप 20 पर काट देते हैं और कुछ ऐसा सेव कर लेते हैं जो अब कहीं नहीं जाता।
जो बनाना है, जाँचना नहीं
अगर आपका प्रोडक्ट फ़ेक ईमेल पते नहीं लेता, तो उन्हें साफ़-साफ़ ठुकराइए। पूरी तरह सही पते पर “ईमेल ग़लत है” इस क्षेत्र की सबसे उलझाने वाली ग़लती है: यूज़र स्पेलिंग जाँचता है, दोबारा लिखता है, और फिर वही संदेश पाता है। “हम फ़ेक ईमेल पते नहीं लेते” उतनी ही जगह लेता है और उलझन ख़त्म कर देता है।