वयस्क क्लासिफाइड्स के लिए ईमेल डिलिवरेबिलिटी: वेरिफिकेशन कोड कभी क्यों नहीं पहुंचता

वह विफलता जिसके लिए किसी को अलर्ट नहीं मिलता

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

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

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

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

यह श्रेणी बाकियों से ज़्यादा सख़्ती से क्यों फ़िल्टर होती है

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

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

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

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

वह तकनीकी न्यूनतम जो अब हर इनबॉक्स प्रोवाइडर लागू करता है

एक प्रोवाइडर जिसकी पॉलिसी बिना किसी हिचक के अकाउंट का स्वागत करती है, वह भी अकेले किसी ईमेल को इनबॉक्स में नहीं पहुंचा सकता। 1 फ़रवरी 2024 से, Google हर उस भेजने वाले से, जो Gmail पतों पर मेल भेजता है, चाहे वॉल्यूम कुछ भी हो, एक डॉक्यूमेंटेड न्यूनतम स्तर पूरा करने की मांग करता है: कम से कम, सेंडिंग डोमेन पर सही तरीके से कॉन्फ़िगर किया गया SPF या DKIM। SPF यह सूचीबद्ध करता है कि कौन-से सर्वर उस डोमेन की ओर से भेजने के लिए अधिकृत हैं; DKIM हर संदेश पर हस्ताक्षर करता है ताकि प्राप्तकर्ता सर्वर यह पुष्टि कर सके कि रास्ते में उसमें कोई फेरबदल नहीं हुआ। जो भेजने वाले ख़ासतौर पर Gmail पतों पर रोज़ाना 5,000 संदेशों तक पहुंचते हैं, उन्हें एक ऊंची बाधा का सामना करना पड़ता है: SPF और DKIM दोनों साथ में, साथ ही डोमेन पर पब्लिश किया गया DMARC, कम से कम मॉनिटरिंग मोड में। कोई क्लासिफाइड्स साइट जो असली स्तर पर उम्र सत्यापन कोड, पासवर्ड रीसेट, और भुगतान रसीदें भेजती है, वह 5,000 संदेशों की यह सीमा तेज़ी से पार कर जाती है, क्योंकि इनमें से हर एक इस कुल संख्या में गिना जाता है।

Google के अपने प्रकाशित दिशानिर्देश ऑथेंटिकेशन के ऊपर एक पक्का आंकड़ा तय करते हैं: किसी भी आकार के भेजने वालों को Google के Postmaster Tools के ज़रिए रिपोर्ट की गई स्पैम शिकायत दर को 0.30 प्रतिशत से नीचे रखना होगा, और वही दिशानिर्देश 0.30 प्रतिशत को एक आरामदायक लक्ष्य मानने के बजाय, एक असली सुरक्षा मार्जिन के तौर पर 0.10 प्रतिशत से नीचे रहने की सलाह देते हैं। पालन न करने पर एक अस्पष्ट सज़ा की बजाय दो अलग-अलग, अलग-अलग तरीक़े से दर्ज की गई विफलताएं सामने आती हैं। जो मेल SPF, DKIM, या DMARC में फ़ेल हो जाता है, उसे स्पैम के तौर पर चिह्नित किया जा सकता है या सीधे 5.7.26 SMTP एरर के साथ अस्वीकार किया जा सकता है। जो भेजने वाले Google द्वारा दी गई सेंडिंग कोटा से आगे निकल जाते हैं, वे एक अलग दीवार से टकराते हैं, एक 4.7.28 रेट-लिमिट एरर। इनमें से कोई भी यह ऐलान नहीं करता कि "यह इंडस्ट्री यहां स्वागत योग्य नहीं है"। किसी डेवलपर के डैशबोर्ड से देखने पर दोनों ही एक आम तकनीकी खराबी जैसे दिखते हैं, और इसी वजह से इन्हें अक्सर उस दिन ठीक करने के बजाय, जिस दिन शुरू हुए, हफ़्तों बाद नोटिस किया जाता है।

Yahoo, जिसका इन्फ्रास्ट्रक्चर AOL पतों को भी सेवा देता है, स्वतंत्र रूप से इसी तरह की शर्त प्रकाशित करता है: SPF और DKIM साथ में, कम से कम p=none वाली एक DMARC पॉलिसी जिसे पास होना ज़रूरी है, और शिकायत दर पर वही 0.30 प्रतिशत की सीमा, फ़रवरी 2024 से उसी समयसीमा में लागू। जो ऑपरेटर Gmail के लिए इसे हल कर लेता है और मान लेता है कि Yahoo और AOL भी उसी राह पर चलेंगे, वह ज़्यादातर मामलों में मशीनरी को लेकर सही होता है, क्योंकि दोनों प्रोवाइडर लगभग एक जैसे आंकड़ों पर पहुंच गए हैं, लेकिन दोनों सिस्टम अब भी अलग-अलग तरीके से मापते और नियम लागू करते हैं, इसलिए जो डोमेन एक के साथ अच्छी स्थिति में है, वह दूसरे के साथ अपने आप अच्छी स्थिति में नहीं होता।

इस पूरे सेट में से एक शर्त जान-बूझकर संकरी लिखी गई है। List-Unsubscribe हेडर का इस्तेमाल करते हुए एक-क्लिक अनसब्सक्राइब, Google के अपने शब्दों में, ख़ासतौर पर मार्केटिंग मैसेज और सब्सक्राइब किए गए मैसेज पर लागू होता है। वेरिफिकेशन कोड या पेमेंट रसीद इनमें से कोई भी नहीं है, इसलिए यह ख़ास लाइन इन्हें निशाना नहीं बनाती। इसके ऊपर मौजूद ऑथेंटिकेशन और रेप्युटेशन की शर्तें, SPF, DKIM, DMARC, और शिकायत की सीमा, इस तरह सीमित नहीं हैं: वे किसी डोमेन द्वारा भेजे गए हर संदेश पर लागू होती हैं, ट्रांज़ैक्शनल मेल सहित।

वह गलती जो ज़रूरी मेल को भी अपने साथ नीचे खींच ले जाती है

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

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

समाधान संरचनात्मक है, यह कोई ऐसी सेटिंग नहीं जिसे शिकायतों का उछाल हो चुकने के बाद बदला जाए। ट्रांज़ैक्शनल मेल, वेरिफिकेशन कोड, पेमेंट कन्फ़र्मेशन, पासवर्ड रीसेट, को एक ऐसे समर्पित सबडोमेन से भेजें जो और किसी काम में नहीं आता, जैसे नंगे डोमेन या साझा मार्केटिंग सबडोमेन के बजाय mail.example.com, और इसे सभी स्ट्रीम्स में दोहराई जाने वाली एक ही कुंजी के बजाय अपनी ख़ुद की DKIM कुंजी से साइन करें। मार्केटिंग कंटेंट या न्यूज़लेटर को एक पूरी तरह अलग सबडोमेन से भेजें, जैसे news.example.com, जिसके अपने ऑथेंटिकेशन रिकॉर्ड और अपनी रेप्युटेशन हो, जो शिकायतों वाले किसी बुरे हफ़्ते को उस मेल को साथ खींचे बिना झेल सके जिसे हर हाल में पहुंचना ज़रूरी है। दोनों स्ट्रीम्स प्रोवाइडर के पास एक ही अकाउंट से गुज़र सकती हैं, लेकिन प्राप्तकर्ता मेल सर्वर की नज़र में उन्हें साफ़ तौर पर अलग-अलग भेजने वालों जैसा दिखना, और उसी तरह साइन होना ज़रूरी है।

इस हफ़्ते वाक़ई क्या जांचना चाहिए

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

जांच करें कि जो डोमेन अभी वेरिफिकेशन और रसीद के ईमेल भेज रहा है, उस पर SPF, DKIM, और DMARC वाक़ई पब्लिश हैं और पास हो रहे हैं, यह मान लेने के बजाय कि वे सही हैं क्योंकि किसी ने उन्हें बरसों पहले एक बार कॉन्फ़िगर किया था। एक DNS रिकॉर्ड जो लिखे जाने के वक़्त सही था, वह किसी प्रोवाइडर माइग्रेशन के बाद पुराना पड़ सकता है, और ऑथेंटिकेशन से रहित डोमेन हर संदेश को उन नियमों के तहत रिजेक्शन के एक असली मौक़े के साथ शुरू करता है जो Google और Yahoo फ़रवरी 2024 से लागू कर रहे हैं, संदेश में जो भी लिखा हो उससे बेपरवाह।

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

प्रोवाइडर की अपनी रिपोर्टिंग या Google के Postmaster Tools के ज़रिए एक तय शेड्यूल पर असली शिकायत दर पर नज़र रखें, और 0.10 प्रतिशत की तरफ़ किसी भी बढ़त को जांच का बिंदु मानें, न कि 0.30 प्रतिशत को, क्योंकि 0.30 प्रतिशत उस बिंदु के ज़्यादा क़रीब है जहां मेल रिजेक्ट होना शुरू होता है, बजाय उस बिंदु के जहां कोई समस्या शुरू होती है। और समय-समय पर किसी पर्सनल Gmail और पर्सनल Yahoo पते पर एक असली टेस्ट साइनअप भेजें, और यह देखें कि कोड पहुंचने में कितना वक़्त लगता है और कहां पहुंचता है, क्योंकि जो डैशबोर्ड एक सफल भेजाव की रिपोर्ट करता है, वह यह बताता है कि सर्वर से क्या निकला, न कि यूज़र ने वाक़ई क्या देखा।