चीनी के लिए SendGrid एक डिक्री नहीं है

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

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

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

यह पता चला कि "बाउंस" का अर्थ है कि मेल सर्वर ने मेल को स्वीकार कर लिया था, लेकिन इसे वितरित नहीं कर सका। यह पता लगाना शेष है कि ये "बाउंस" क्यों होते हैं, और मैंने SendGrid समर्थन से एक प्रश्न के साथ संपर्क किया कि ऐसा क्यों होता है और दो प्रकार के बाउंस जो मुझे sendgrid.com/logs/index पर मिले हैं , वे फ़िल्टर के साथ खेलते समय भिन्न होते हैं :



जवाब में, मुझे प्रलेखन पृष्ठ का लिंक मिला - sendgrid.com/docs/Delivery_Metrics/index.html , और यह भी पता चला कि सेंडग्रिड बाउंस को नरम और कठोर में विभाजित करता है। उन्होंने मुझे sendgrid.com/bounce पेज पर भी आने का इशारा किया, जो मैं तब तक नहीं पहुंचा था। इस पर आप पा सकते हैं कि जब पता बाउंस सूची में था, और आप इस सूची के पते हटा सकते हैं। यहां पहली बार मैंने सोचा कि ऐसा करने के लिए एक स्वचालित तरीका होना चाहिए, क्योंकि यह हमारे संस्करणों की सूचियों को देखने, विश्लेषण करने और उन्हें मैन्युअल रूप से साफ करने के लिए अवास्तविक होगा। मुझे बताया गया था कि SendGrid सभी बाद के पत्रों को ऐसे पते पर नहीं भेजता है जो इस तरह की सूची में हैं जब तक कि हम खुद इसे इस सूची से नहीं हटाते हैं। "जी!" - मैंने एक गैर-साहित्यिक रूप में सोचा, और फिर से समर्थन सेवा को लिखा। बहुत सारे सवाल थे - हालाँकि ऐसा लगता है कि SendGrid ने प्रलेखन में इस पर विस्तार से वर्णन किया है। फंड की कमी के रूप में अगर वे नहीं होना चाहिए, CrunchBase के अनुसार।

मेरी राय में, यह कहने के लिए गतिविधि लॉग में यह काफी तार्किक होगा:
- इस पते पर "bruce.lee@our_client_domain.asia" पते पर भेजने का प्रयास "इस तरह के और इस तरह के" के जवाब में ले गया -> मैंने सूची में "हार्ड उछाल" का पता लगाया
- पता भेजने के लिए यह प्रयास "bruce.lee@our_client_domain.asia" स्थिति "ड्रॉप" के साथ नजरअंदाज कर दिया है, क्योंकि पता पहले से ही "हार्ड उछाल" सूची में है। गिराए गए सभी प्रयासों और प्राथमिक सर्वर प्रतिक्रिया को देखने के लिए, sendgrid.com/bounce/bruce.lee@our_client_domain.asia पर जाएं ।

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

मेल को सूची में गिरने से रोकने के लिए, मुझे सलाह दी गई थी कि हमारे सदस्यता स्तर - सिल्वर के लिए उपलब्ध पता श्वेतसूची आवेदन में डोमेन जोड़ दें, लेकिन यह भी एक विकल्प नहीं है। प्रदाता को मेल भेजना जारी है, जिसमें आपको काली सूची में शामिल किया गया था (ब्लैक लिस्टेड यू) कारणों को स्पष्ट किए बिना, एक दृष्टिकोण के रूप में, हम खुश नहीं थे।

आगे यह और भी दिलचस्प था। रिपोर्टों में, मैंने मूल कारण - "550 कनेक्शन आवृत्ति सीमित" पाया। क्लाइंट से मुझे पता था कि उनका ईएसपी चीन, क्यूक्यू.कॉम में सबसे बड़ा आईएसपी है, और यह भी कि क्लाइंट ने हमारे डोमेन को श्वेत सूची में जोड़ा, और इससे कोई फायदा नहीं हुआ। क्लाइंट ने बेसकैंप में जाने की धमकी दी (जो, ज़ाहिर है, अप्रिय है)। इसके अलावा, ग्राहक ने यह जानकारी साझा की कि QQ के पास प्रत्येक उपयोगकर्ता द्वारा प्राप्त मेल की मात्रा की सीमा है। इसने बताया कि कुछ उपयोगकर्ताओं को हमें मेल क्यों मिला, जबकि अन्य को नहीं मिला। क्लाइंट ने समझाया कि क्यूक्यू अपने उपयोगकर्ताओं को बड़ी मात्रा में मेल भेजने के लिए छोटे ईएसपी (इस मामले में, हमें) की अनुमति नहीं देता है। एक वाजिब सवाल खड़ा हुआ - इस मामले में ईएसपी कौन है, हम या सेंडग्रिड? यह पता चला कि हम हैं, और यह पूरी तरह से हमारी समस्या है। QQ ने उदाहरण के लिए, स्थापित किया है कि सभी प्रेषक (जिन्हें वे बड़े मानते हैं) प्रत्येक उपयोगकर्ता को प्रति दिन 10 से अधिक पत्र नहीं भेज सकते हैं। जाहिरा तौर पर, जैसे ही हमारे उपयोगकर्ताओं में से एक को ये सामान्यीकृत QQ संदेश हम से प्राप्त होते हैं, हम आगे [550 कनेक्शन आवृत्ति सीमित] त्रुटि प्राप्त करते हैं, जैसा कि Erast Fandorin - Mas कहते हैं, और हम मध्य साम्राज्य में आने के लिए नए दिन की प्रतीक्षा कर रहे हैं एक और दस भेजने के लिए। इसके अलावा, हम SendGrid उछाल सूची में भी समाप्त होते हैं और हमारे इस उपयोगकर्ता को मेल भेजना बंद हो जाता है जब तक कि हम इस सूची से पता नहीं हटाते हैं (हम जानते हैं कि हम नियमित रूप से वहां पहुंचेंगे)।

वैसे, यदि आप Google में "550 कनेक्शन आवृत्ति सीमित" लाइन पर खोज करते हैं, तो आप तुरंत देखेंगे कि सभी लिंक या तो QQ.com का उल्लेख करते हैं, या स्वयं QQ.com के पृष्ठ हैं। यही है, यह एक ज्ञात मुद्दा है। एक कहना चाहूंगा - "मैं अपने प्रिय को गैट द्वारा पहचानता हूं, और क्यूक्यू - कनेक्शन आवृत्ति सीमित द्वारा।"



SendGrid को इस बारे में कुछ क्यों नहीं पता है और चेतावनी नहीं है - "आप लोग क्यूक्यू मेल भेज रहे हैं, लानत है, ध्यान रखें कि ...."? SendGrid QQ से सहमत क्यों नहीं है कि QQ उनके (SendGrid) ग्राहकों के लिए प्रतिबंध के बिना मेल स्वीकार करता है, या कम से कम इस बाजार में एक प्रमुख खिलाड़ी होने के नाते एक मध्यस्थ की भूमिका पर ले जाता है?

इसके अलावा, चीन के एक ग्राहक ने हमें (क्यू!) की भविष्यवाणी करने की सलाह दी। क्यूक्यू द्वारा हमारे सभी ग्राहकों को भेजे गए मेल की मात्रा, ताकि एक ही उपयोगकर्ता को कई पत्र न भेजें। आप इसकी कल्पना कैसे करते हैं? मैं नहीं करता। या मदद के लिए SendGrid से संपर्क करें, जो हमने किया।

सेंडग्रिड ने उत्तर दिया कि, दुर्भाग्य से, QQ पृष्ठ चीनी में है (अर्थात, ऐसा लगता है जैसे उन्होंने पहली बार हमसे इस तरह की समस्या के बारे में सीखा था, लेकिन वे अभी भी ऑनलाइन अनुवादकों के अस्तित्व के बारे में नहीं जानते हैं)। उन्होंने यह भी कहा कि हमें स्वयं क्यूक्यू से संपर्क करने और उन्हें अपना निवर्तमान आईपी पता भेजने की आवश्यकता है, और आने वाले पत्रों पर प्रतिबंध हटाने के लिए कहें। SendGrid ने $ 20 प्रति माह अतिरिक्त IP पते खरीदने का भी सुझाव दिया ताकि कुछ मेल उनसे भेजे जा सकें। एक "अच्छा" समाधान, लेकिन QQ से आईपी द्वारा अवरुद्ध करने की संभावना क्या है (शायद वे डोमेन द्वारा ब्लॉक करते हैं)? इस मामले का अंत था।

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

यह वह और अन्य मामले थे जिन्होंने हमें समस्या समाधान के विश्लेषण और भविष्य के स्वचालन के लिए मेल भेजने की स्थिति बनाए रखने के निर्णय के लिए नेतृत्व किया। यह स्पष्ट हो गया कि आपको अपने डेटाबेस में भेजे गए पत्रों की स्थिति के बारे में जानकारी एकत्र करने की आवश्यकता है, और फिर अपने दम पर मेल समस्याओं के समाधान को स्वचालित करने के सवाल पर वापस लौटें।

ऊपर वर्णित स्थिति से क्या निष्कर्ष निकाला जा सकता है:

1) Sendrgid आपको उपयोगकर्ता के मेल सर्वर साइड पर ब्लॉक करने से बिल्कुल भी बचाता नहीं है। यदि आपके ग्राहक शिकायत करते हैं कि उन्हें सूचनाएं प्राप्त नहीं होती हैं, तो जांच लें कि क्या उनके ईएसपी पर QQ की तरह प्रतिबंध है।

2) Sendgrid के कार्यकर्ता चीनी नहीं जानते हैं

3) Sendgrid के माध्यम से पत्र भेजते समय, आपको ईवेंट webhook का उपयोग करना चाहिए, या बाउंस सूची में अपने उपयोगकर्ताओं को रखने के लिए तुरंत प्रतिक्रिया देने के लिए सेवा में अपना खाता नियमित रूप से देखना चाहिए।