लेन-देन ईमेल के लिए SMTP रिले सेटअप
लेन-देन के ईमेल के लिए SMTP रिले सेटअप सीखें, डोमेन सत्यापन से लेकर प्रमाणीकरण, डिलीवरी के मूलभूत सिद्धांतों और सर्वोत्तम प्रथाओं तक।

लेन-देन ईमेल के लिए SMTP रिले का क्या अर्थ है
SMTP रिले तकनीकी लगता है, लेकिन विचार सीधा है। आपका एप्लिकेशन एक ईमेल बनाता है, उसे एक मेल सर्वर को सौंपता है, और वह सर्वर इसे प्राप्तकर्ता के इनबॉक्स में पहुंचाने की जिम्मेदारी लेता है। दूसरे शब्दों में, रिले आपके ऐप और व्यापक ईमेल नेटवर्क के बीच मध्य चरण के रूप में कार्य करता है।
लेन-देन ईमेल के लिए, वह मध्य चरण बहुत महत्वपूर्ण है। पासवर्ड रीसेट, रसीद ईमेल, खाता अलर्ट, सत्यापन लिंक, और शिपिंग अपडेट सभी को तेजी से और विश्वसनीयता से आगे बढ़ने की आवश्यकता होती है। यदि आपका ऐप इन संदेशों को अपने दम पर भेजने की कोशिश करता है, तो डिलीवरी असंगत हो सकती है, खासकर यदि सर्वर नया, खराब कॉन्फ़िगर किया गया है, या विश्वसनीय भेजने के इतिहास की कमी है।
एक SMTP रिले आपकी ओर से आउटबाउंड मेल प्रवाह को संभालने में मदद करता है। आपका एप्लिकेशन आमतौर पर प्रमाणीकरण के साथ SMTP के माध्यम से संदेश प्रस्तुत करता है, और फिर रिले सेवा आपके behalf पर प्राप्तकर्ता मेल सर्वरों से जुड़ती है। यह व्यवस्था उपयोगी है क्योंकि रिले प्रदाता आमतौर पर उचित IP प्रतिष्ठा बनाए रखता है, पुनः प्रयासों का प्रबंधन करता है, और प्रमुख मेलबॉक्स प्रदाताओं के वितरण नियमों को समझता है।
साफ-साफ कहें: आपका ऐप संदेश लिखता है, रिले इसे आगे बढ़ाता है, और प्राप्तकर्ता का मेल सर्वर तय करता है कि आगे क्या होगा। यह विभाजन एक कारण है कि लेन-देन ईमेल के लिए SMTP रिले सेटअप इतना सामान्य है। यह मेल भेजने की लॉजिक को आपके एप्लिकेशन से बाहर रखता है जबकि महत्वपूर्ण संदेशों के वास्तव में पहुंचने की संभावनाओं को बढ़ाता है।
लेन-देन ईमेल बनाम मार्केटिंग ईमेल
लेन-देन ईमेल और मार्केटिंग ईमेल दोनों एक ही परिवहन परत के माध्यम से यात्रा कर सकते हैं, लेकिन वे बहुत अलग उद्देश्यों की सेवा करते हैं। लेन-देन संदेश उपयोगकर्ता क्रिया या खाता घटना द्वारा ट्रिगर होते हैं। उदाहरण के लिए, पासवर्ड रीसेट अनुरोध व्यक्तिगत, तात्कालिक, और अपेक्षित होता है। इसके विपरीत, मार्केटिंग ईमेल आमतौर पर बैच में योजना बनाई जाती है और प्रचारात्मक या सूचनात्मक उद्देश्यों के लिए एक बार में कई प्राप्तकर्ताओं को भेजी जाती है।
यह अंतर यह बदलता है कि प्रत्येक प्रकार को कैसे भेजा जाना चाहिए। लेन-देन ईमेल समय पर, प्रासंगिक, और कम-फ्रिक्शन होना चाहिए। यदि कोई लॉगिन लिंक के लिए पूछता है, तो वह संदेश न्यूज़लेटर विस्फोट के पीछे कतार में नहीं बैठना चाहिए। मार्केटिंग ईमेल अक्सर विभाजन, अभियान अनुसूची, अनसब्सक्राइब प्रबंधन, और व्यापक अनुपालन जांचों में शामिल होता है। ये आवश्यकताएँ महत्वपूर्ण हैं, लेकिन वे लेन-देन मेल की संचालन प्राथमिकताओं के समान नहीं हैं।
डिलीवरी व्यवहार भी भिन्न होता है। लेन-देन संदेशों को गति और स्थिरता के आधार पर आंका जाता है। मार्केटिंग भेजने की संभावना अधिक होती है कि वे फ़िल्टरिंग जांच को ट्रिगर करें क्योंकि वे बड़े, अधिक दोहराव वाले, और कभी-कभी कम व्यक्तिगत रूप से अपेक्षित होते हैं। दोनों को मिलाने से समस्या उत्पन्न हो सकती है। यदि मार्केटिंग अभियान पर शिकायत दरें बढ़ती हैं, तो प्रतिष्ठा का नुकसान महत्वपूर्ण खाता ईमेल पर फैल सकता है। यही कारण है कि कई टीमें लेन-देन और प्रचारात्मक मेल के लिए अलग सिस्टम, अलग प्रेषक पहचान, या कम से कम अलग ट्रैफ़िक पथ बनाए रखती हैं।
उन्हें अलग करने का एक व्यावहारिक कारण भी है: समर्थन और डिबगिंग आसान होती है। यदि पासवर्ड रीसेट विफल हो जाता है, तो आप जानना चाहेंगे कि समस्या प्रमाणीकरण, DNS, कतारबद्धता, या प्रदाता ब्लॉक से आई थी। यदि वही रिले न्यूज़लेटर्स को भी संभाल रहा है, तो सिग्नल बहुत जल्दी धुंधला हो जाता है।
SMTP रिले सेटअप के लिए पूर्वापेक्षाएँ
एक कार्यशील SMTP रिले सेटअप आमतौर पर कुछ बुनियादी चीजों के साथ शुरू होता है। इनमें से कोई भी असामान्य नहीं है, लेकिन प्रत्येक महत्वपूर्ण है।
- एक भेजने वाला डोमेन जिसे आप नियंत्रित करते हैं
- एक रिले प्रदाता से प्रमाणित SMTP क्रेडेंशियल्स
- उस डोमेन के लिए DNS रिकॉर्ड्स तक पहुंच
- एक एप्लिकेशन या सिस्टम जो SMTP के माध्यम से मेल भेज सकता है
- एक लेनदेनात्मक ईमेल प्रदाता या रिले सेवा
पहले, आपको एक डोमेन की आवश्यकता है जो आपके ईमेल हेडर और भेजने वाले पते में दिखाई देगा। एक वास्तविक डोमेन का उपयोग करना जो आपके नियंत्रण में है, महत्वपूर्ण है क्योंकि प्राप्तकर्ता और मेलबॉक्स प्रदाता इसकी अपेक्षा करेंगे कि यह आपके प्रमाणीकरण रिकॉर्ड से मेल खाता हो।
दूसरे, आपको SMTP क्रेडेंशियल्स की आवश्यकता है। ये अक्सर एक उपयोगकर्ता नाम और पासवर्ड होते हैं, हालांकि कुछ प्रदाता API कुंजी या गुप्त टोकन का उपयोग करते हैं जो SMTP पहुंच से मेल खाते हैं। मुख्य बिंदु यह है कि आपके एप्लिकेशन को यह साबित करना होगा कि इसे रिले के माध्यम से मेल भेजने की अनुमति है।
तीसरे, आपको DNS पहुंच की आवश्यकता है। यहीं पर आप SPF, DKIM, और DMARC रिकॉर्ड प्रकाशित करते हैं, साथ ही किसी भी प्रदाता-विशिष्ट सत्यापन रिकॉर्ड भी। यदि आप DNS संपादित नहीं कर सकते हैं, तो सेटअप सबसे महत्वपूर्ण चरण पर रुक जाएगा।
अंत में, आपको एक एप्लिकेशन की आवश्यकता है जो SMTP से बात कर सके। अधिकांश वेब फ्रेमवर्क, CRM, टिकटिंग सिस्टम, और कस्टम सेवाएं ऐसा कर सकती हैं। यदि आपका ऐप एक होस्ट, पोर्ट, उपयोगकर्ता नाम, पासवर्ड, और भेजने वाले पते को निर्दिष्ट कर सकता है, तो आप शायद अच्छे आकार में हैं।
चरण-दर-चरण SMTP रिले सेटअप
हालांकि प्रदाता भिन्न होते हैं, सेटअप प्रक्रिया आमतौर पर एक ही आकार का पालन करती है। विवरण बदलते हैं, लेकिन अनुक्रम परिचित रहता है।
1. एक रिले सेवा चुनें
एक प्रदाता चुनें जो लेनदेनात्मक ईमेल का समर्थन करता है और आपको SMTP पहुंच देता है। स्पष्ट दस्तावेज़ीकरण, विश्वसनीय डिलीवरी उपकरण, और लॉग की तलाश करें जो आपको व्यक्तिगत संदेशों का पता लगाने की अनुमति देते हैं।
2. अपने भेजने वाले डोमेन की पुष्टि करें
अधिकांश रिले सेवाएं आपसे उस डोमेन के स्वामित्व को साबित करने के लिए कहती हैं जिससे आप भेजेंगे। इसका अक्सर मतलब है कि प्रदाता द्वारा प्रदान किए गए एक या अधिक DNS रिकॉर्ड जोड़ना। कुछ सेवाएं स्वामित्व के लिए एक सत्यापन रिकॉर्ड का उपयोग करती हैं, फिर प्रमाणीकरण के लिए अलग DNS रिकॉर्ड। प्रदाता के निर्देशों का ध्यानपूर्वक पालन करें; DNS में एक टाइपो घंटों बर्बाद कर सकता है।
3. SMTP होस्ट और पोर्ट कॉन्फ़िगर करें
अपने एप्लिकेशन में SMTP सर्वर विवरण दर्ज करें। प्रदाता एक होस्ट नाम और एक या अधिक पोर्ट निर्दिष्ट करेगा। कई सेटअप में, एन्क्रिप्टेड सबमिशन को प्राथमिकता दी जाती है। अनुमान लगाने के बजाय अनुशंसित सुरक्षित पोर्ट चुनें। यदि आपका नेटवर्क या होस्टिंग वातावरण आउटबाउंड SMTP को ब्लॉक करता है, तो आपको अपने बुनियादी ढांचे की टीम या होस्टिंग प्रदाता से इसे अनुमति देने के लिए पूछना पड़ सकता है।
4. प्रमाणीकरण सक्षम करें
रिले द्वारा प्रदान किए गए उपयोगकर्ता नाम और पासवर्ड, टोकन, या कुंजी का उपयोग करें। प्रमाणीकरण सेवा को बताता है कि आपका एप्लिकेशन इसके बुनियादी ढांचे के माध्यम से संदेश भेजने के लिए अधिकृत है। इसके बिना, रिले आमतौर पर आपके संदेशों को अस्वीकार कर देगा। क्रेडेंशियल्स को स्रोत नियंत्रण से बाहर रखें और इसके बजाय पर्यावरण चर या एक गुप्त प्रबंधक का उपयोग करें।
5. अपने भेजने के पते को ध्यान से सेट करें
आपके लिफाफे के भेजने वाले और दृश्य में दिखने वाले पते को उस डोमेन के साथ मेल खाना चाहिए जिसे आपने सत्यापित किया है। एक असंगत पते से भेजा गया संदेश अभी भी स्वीकार किया जा सकता है, लेकिन यह फ़िल्टर और प्राप्तकर्ताओं के लिए संदिग्ध दिखने की अधिक संभावना है। एक स्थिर, पहचानने योग्य भेजने वाली पहचान उपयोगकर्ताओं को संदेश पर भरोसा करने में मदद करती है।
6. एक परीक्षण संदेश भेजें
उत्पादन ट्रैफ़िक को रूट करने से पहले, एक वास्तविक मेलबॉक्स में पहला संदेश भेजें जिसे आप निरीक्षण कर सकें। जांचें कि संदेश पहुंचता है, कि विषय और सामग्री सही दिखते हैं, और कि हेडर आपकी रिले पथ को अपेक्षित रूप से दिखाते हैं। यदि प्रदाता संदेश लॉग प्रदान करता है, तो लॉग प्रविष्टि की तुलना मेलबॉक्स की प्रति से करें। यह छोटा आदत बाद में बहुत सारे अनुमान बचाता है।
यदि संभव हो तो एक से अधिक मेलबॉक्स प्रदाता से परीक्षण करना भी सार्थक है। एक प्रदाता एक संदेश को साफ-सुथरा स्वीकार कर सकता है जबकि दूसरा इसे स्पैम में डाल सकता है या इसे देरी कर सकता है। यह अंतर प्रारंभिक रूप से प्रमाणीकरण या प्रतिष्ठा की समस्याओं को उजागर कर सकता है।
प्रमाणीकरण, SPF, DKIM, और DMARC
ईमेल प्रमाणीकरण मेलबॉक्स प्रदाताओं को यह संकेत देता है कि क्या एक संदेश वैध है। लेन-देन संबंधी ईमेल के लिए, यह महत्वपूर्ण है क्योंकि सामग्री अक्सर तात्कालिक और विश्वसनीय होने की अपेक्षा की जाती है। यदि प्रमाणीकरण कमजोर या असंगत है, तो डिलीवरी प्रभावित हो सकती है, भले ही संदेश स्वयं पूरी तरह से ठीक हो।
SPF, DKIM, और DMARC तीन रिकॉर्ड हैं जिनके बारे में अक्सर एक साथ चर्चा की जाती है। SPF यह निर्धारित करने में मदद करता है कि कौन से सर्वर आपके डोमेन के लिए मेल भेजने की अनुमति है। DKIM संदेश में एक क्रिप्टोग्राफिक हस्ताक्षर जोड़ता है ताकि प्राप्त करने वाला सर्वर यह पुष्टि कर सके कि इसे ट्रांजिट में बदला नहीं गया था। DMARC प्राप्तकर्ताओं को बताता है कि वे उन संदेशों के साथ कैसे व्यवहार करें जो संरेखण जांच में विफल होते हैं और आपको रिपोर्टिंग दृश्यता प्रदान करता है।
एक सामान्य SMTP रिले सेटअप में, रिले प्रदाता आपके पक्ष में मेल भेजता है, लेकिन रिकॉर्ड अभी भी एक विश्वसनीय व्यवस्था की ओर इशारा करना चाहिए। इसका मतलब है कि यदि आवश्यक हो तो आपका SPF रिकॉर्ड प्रदाता को शामिल करना चाहिए, और आपकी DKIM सेटअप को उस साइनिंग डोमेन या चयनकर्ता से मेल खाना चाहिए जिसका उपयोग प्रदाता करता है। DMARC फिर दृश्यता से डोमेन और प्रमाणित पहचान के बीच संरेखण की जांच करके टुकड़ों को एक साथ जोड़ता है।
महत्वपूर्ण बात निरंतरता है। यदि आप एक डोमेन से भेजते हैं, दूसरे के साथ प्रमाणित करते हैं, और तीसरे के लिए रिकॉर्ड प्रकाशित करते हैं, तो डिलीवरी गड़बड़ हो जाती है। भेजने वाले डोमेन, DNS रिकॉर्ड, और रिले कॉन्फ़िगरेशन को एक ही परिवार में रखें। यह ग्लैमरस काम नहीं है, लेकिन यह वही प्रकार का गैर-ग्लैमरस सेटअप है जो पासवर्ड रीसेट को स्पैम फ़ोल्डरों से बाहर रखता है।
सामान्य डिलीवरी समस्याएँ और उन्हें कैसे हल करें
एक ठोस सेटअप के बावजूद, डिलीवरी की समस्याएँ होती हैं। अच्छी खबर यह है कि उनमें से अधिकांश कुछ पहचाने जाने वाले पैटर्न में आती हैं।
अमान्य क्रेडेंशियल्स
यदि रिले तुरंत आपके संदेश को अस्वीकार करता है, तो पहले उपयोगकर्ता नाम, पासवर्ड, टोकन, या API कुंजी की जांच करें। क्रेडेंशियल्स अक्सर पर्यावरण चर, तैनाती रहस्यों, या कॉन्फ़िगरेशन फ़ाइलों में कॉपी किए जाते हैं, और एक अतिरिक्त स्थान सब कुछ तोड़ सकता है। पुष्टि करें कि खाता सक्रिय है और इसे आप जिस डोमेन का उपयोग कर रहे हैं, उससे भेजने की अनुमति है।
ब्लॉक किए गए पोर्ट या नेटवर्क प्रतिबंध
कभी-कभी एप्लिकेशन रिले तक बिल्कुल नहीं पहुँचता। होस्टिंग वातावरण, फ़ायरवॉल, या क्लाउड सुरक्षा नियम आउटबाउंड SMTP पोर्ट को ब्लॉक कर सकते हैं। यदि आपकी संदेश कतार एक अस्वीकरण के बजाय टाइमआउट दिखाती है, तो प्रमाणीकरण समस्याओं का पीछा करने से पहले नेटवर्क एक्सेस पर ध्यान दें।
स्पैम फ़िल्टरिंग या खराब इनबॉक्स प्लेसमेंट
यदि संदेश तकनीकी रूप से स्वीकार किए जाते हैं लेकिन स्पैम में पहुँचते हैं, तो पहले सामग्री और प्रमाणीकरण की जांच करें। गायब SPF, कमजोर DKIM संरेखण, या संदिग्ध नाम सभी इनबॉक्स प्लेसमेंट को नुकसान पहुँचा सकते हैं। भेजने की मात्रा में अचानक परिवर्तन या खराब सूची स्वच्छता भी ऐसा कर सकती है। लेन-देन संबंधी मेल आमतौर पर मार्केटिंग मेल की तुलना में कम संवेदनशील होता है, लेकिन यह प्रतिरक्षित नहीं है।
संदेश स्थगन
एक स्थगन का मतलब है कि प्राप्तकर्ता सर्वर ने प्रेषक से बाद में फिर से प्रयास करने के लिए कहा। यह तब हो सकता है जब प्राप्तकर्ता सर्वर व्यस्त, सतर्क, या आपकी प्रतिष्ठा से असंतुष्ट हो। एक अच्छा रिले स्वचालित रूप से फिर से प्रयास करेगा। यदि स्थगन सामान्य हैं, तो अपने प्रेषक की प्रतिष्ठा, प्रमाणीकरण, और यह जांचें कि क्या आप एक शोर वाले मेल स्ट्रीम के साथ बुनियादी ढाँचा साझा कर रहे हैं।
गायब या गलत हेडर
कुछ समस्याएँ संदेश के कारण होती हैं। एक टूटी हुई विषय पंक्ति, गलत MIME संरचना, या गलत एन्कोडिंग मेल क्लाइंट या फ़िल्टर को भ्रमित कर सकती है। यदि एक संदेश केवल इनबॉक्स में अजीब दिखता है, तो कच्चे स्रोत की तुलना एक ज्ञात-अच्छे परीक्षण संदेश से करें। छोटे प्रारूपण त्रुटियाँ बड़े वितरण सिरदर्द पैदा कर सकती हैं।
विश्वसनीय लेनदेनात्मक ईमेल के लिए सर्वोत्तम प्रथाएँ
लेनदेनात्मक ईमेल में विश्वसनीयता छोटे आदतों के एक ढेर से आती है। इनमें से कोई भी नाटकीय नहीं है, लेकिन एक साथ मिलकर ये प्रणाली को अधिक स्थिर बनाते हैं।
- प्राप्तकर्ता संदेश को पहचान सकें, इसलिए पते और प्रेषक नामों का उपयोग लगातार करें
- लेनदेनात्मक ट्रैफ़िक को विपणन भेजने से अलग रखें
- नियमित रूप से बाउंस प्रतिक्रियाओं और विफलता लॉग की निगरानी करें
- अस्थायी वितरण समस्याओं के लिए विचारशीलता से पुनः प्रयास करें
- टेम्पलेट्स को संक्षिप्त और स्पष्ट रखें, विशेष रूप से पासवर्ड रीसेट जैसी तात्कालिक क्रियाओं के लिए
- DNS और SMTP सेटिंग्स में परिवर्तनों को ट्रैक करें ताकि आवश्यकता पड़ने पर आप वापस रोल कर सकें
संगति विश्वास बनाती है। यदि एक उपयोगकर्ता आज एक पते से सत्यापन ईमेल प्राप्त करता है और कल एक अलग पते से, तो वे संकोच कर सकते हैं या इसे हटा सकते हैं। एक स्थिर प्रेषक पहचान समर्थन को भी आसान बनाती है क्योंकि उपयोगकर्ता आपके संदेशों को अधिक विश्वसनीयता से खोज सकते हैं।
बाउंस मॉनिटरिंग को अक्सर जितनी ध्यान देने की आवश्यकता होती है, उतना नहीं मिलता। हार्ड बाउंस खराब पते या समाप्त खातों का संकेत दे सकते हैं, जबकि सॉफ्ट बाउंस अस्थायी प्राप्तकर्ता-पक्ष की समस्याओं की ओर इशारा कर सकते हैं। यदि आप दोनों को अनदेखा करते हैं, तो आप दृश्यता खो देते हैं और पहुंच से बाहर के इनबॉक्स में बार-बार भेजने का जोखिम उठाते हैं।
यह भी समझदारी है कि जहां भी संभव हो, लेनदेन संबंधी ट्रैफ़िक को विपणन ट्रैफ़िक से अलग किया जाए। भले ही वही प्रदाता दोनों को संभाले, अलग डोमेन, उपडोमेन, या समर्पित धाराओं का उपयोग महत्वपूर्ण संदेशों को एक शोर भरे अभियान के दुष्प्रभावों से बचा सकता है। इस तरह, एक प्रचारात्मक भेजना गलती से खाता अलर्ट में हस्तक्षेप नहीं करता है।
SMTP रिले प्रदाता कब चुनें
जब ईमेल भेजना आपके व्यवसाय के लिए महत्वपूर्ण होता है, न कि केवल एक पृष्ठभूमि सुविधा, तो एक समर्पित SMTP रिले प्रदाता अक्सर बेहतर विकल्प होता है। यदि आपके आवेदन को लॉगिन लिंक, बिलिंग नोटिस, डिलीवरी अपडेट, या सुरक्षा अलर्ट भेजने की आवश्यकता है, तो आप चाहते हैं कि डिलीवरी विश्वसनीय और अवलोकनीय हो। एक रिले प्रदाता आमतौर पर ऐप सर्वर से सीधे भेजने की तुलना में उस स्थिरता को अधिक साफ-सुथरे तरीके से प्रदान करता है।
विश्वसनीयता पहला कारण है। एप्लिकेशन सर्वर सॉफ़्टवेयर चलाने के लिए बनाए जाते हैं, न कि मेलबॉक्स प्रदाताओं के साथ बातचीत करने, पुनः प्रयास करने और प्रतिष्ठा को ट्रैक करने के लिए। एक रिले सेवा उस काम के लिए डिज़ाइन की गई है।
स्केलेबिलिटी एक और कारण है। जैसे-जैसे संदेशों की मात्रा बढ़ती है, सीधे भेजना प्रबंधित करना कठिन हो जाता है। आपको आईपी वार्मिंग, कतार प्रबंधन, थ्रॉटलिंग, और दर सीमाओं के बारे में सोचना पड़ सकता है। एक रिले प्रदाता उस परिचालन बोझ का अधिकांश भाग अवशोषित कर सकता है, जो विशेष रूप से सहायक होता है यदि मेल भेजना आपके सिस्टम का केवल एक हिस्सा है।
अनुपालन और शासन भी महत्वपूर्ण हो सकते हैं। टीमों को अक्सर बेहतर लॉग, पहुंच नियंत्रण, खाता विभाजन, या ऑडिट-फ्रेंडली डिलीवरी रिकॉर्ड की आवश्यकता होती है। एक समर्पित रिले उन नीतियों को लागू करना आसान बना सकता है, जो एप्लिकेशन में खुद को सिला हुआ कस्टम मेल पथ से अधिक है।
कुछ मामले हैं जहां एप्लिकेशन सर्वर से सीधे SMTP काम कर सकता है, विशेष रूप से बहुत छोटे आंतरिक उपकरणों या कम मात्रा वाले सिस्टम के लिए। लेकिन एक बार जब लेनदेन संबंधी ईमेल ग्राहक के सामने और व्यवसाय के लिए महत्वपूर्ण हो जाता है, तो रिले मॉडल आमतौर पर नियंत्रण, डिलीवरबिलिटी, और मन की शांति पर जीतता है। और मन की शांति तब बहुत मायने रखती है जब प्रश्न में संदेश एक पासवर्ड रीसेट है जिसका कोई अभी इंतजार कर रहा है।
इस पृष्ठ पर
← सभी लेखएक क्लिक। यह हमें बताता है कि अगला क्या लिखना है।
अभी तक कोई रेटिंग नहीं — आपकी पहली होगी।
टिप्पणियाँ
टिप्पणियाँ दिखाई देने से पहले पढ़ी जाती हैं।