यूरोप की प्रमुख payment processing कंपनी Google Workspace users को ईमेल भेजने में असफल

 (atha.io)
1 पॉइंट द्वारा GN⁺ 2026-02-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यूरोप की बड़ी payment कंपनी Viva.com ने Message-ID header के बिना verification ईमेल भेजे, जिसके कारण Google Workspace server ने उन्हें reject कर दिया
  • RFC 5322 (2008 में निर्धारित) में Message-ID को अनिवार्य स्तर का header माना गया है, और Google इसे सख्ती से लागू करता है
  • व्यक्तिगत Gmail address पर ईमेल प्राप्त हो गया, जिससे Google Workspace और Gmail के processing difference सामने आए
  • Viva.com customer support ने तकनीकी समस्या स्वीकार नहीं की और सिर्फ़ user द्वारा किए गए workaround के नतीजे को देखा, जो गैर-पेशेवर response था
  • यह ऐसा मामला है जहाँ बुनियादी RFC compliance भी नहीं निभाई गई, जिससे यूरोपीय fintech infrastructure की quality और competitiveness में गिरावट का संकेत मिलता है

verification ईमेल के न पहुंचने की समस्या

  • Viva.com account creation के दौरान verification ईमेल बिल्कुल नहीं पहुँचा
    • Google Workspace आधारित custom domain ईमेल का उपयोग किया गया था, और spam folder में भी ईमेल नहीं था
  • Google Workspace की Email Log Search में status “Bounced” दिखा
    • bounce reason था “Messages missing a valid Message-ID header are not accepted”
    • Google ने RFC 5322 specification के उल्लंघन के कारण ईमेल reject कर दिया
  • Viva.com के outgoing ईमेल में Message-ID header गायब था, जबकि यह 2008 से आवश्यक माना जाता रहा है

अस्थायी समाधान

  • व्यक्तिगत @gmail.com address पर बदलते ही verification ईमेल सामान्य रूप से प्राप्त हो गया
    • लगता है Gmail का receiving infrastructure अधिक उदार था या उसने इसे किसी अलग route से process किया
  • लेकिन business payment platform में signup के लिए व्यक्तिगत ईमेल का उपयोग करना पड़ा, इसे अपने आप में समस्या बताया गया

customer support की प्रतिक्रिया

  • Viva.com customer support को Google Workspace log का screenshot और समस्या का विवरण भेजा गया
  • support team ने जवाब दिया, “आपके account में पहले से verified ईमेल है, इसलिए कोई समस्या नहीं है”
    • तकनीकी समस्या की समझ या engineering team तक escalation नहीं हुई
    • user द्वारा खुद किए गए workaround के नतीजे को ही no-issue response की तरह लिया गया

समस्या का मूल

  • Message-ID वह मूल header है जिसे लगभग सभी email system default रूप से बनाते हैं
    • इसका गायब होना बताता है कि mail pipeline गंभीर रूप से गलत configure की गई हो सकती है
  • RFC 5322 में Message-ID को “SHOULD” कहा गया है, लेकिन Google इसे व्यवहार में अनिवार्य (MUST) की तरह मानता है
  • Viva.com द्वारा इसका पालन न करने से Google Workspace users तक ईमेल नहीं पहुँच पाया
  • पूरे यूरोप में payments process करने वाली कंपनी का बुनियादी RFC standard का पालन न कर पाना तकनीकी reliability पर सवाल उठाता है

यूरोपीय fintech infrastructure की संरचनात्मक समस्या

  • यूरोप की enterprise API और services में अधूरा documentation, कमजोर error handling, और गैर-पेशेवर support बार-बार देखने को मिलता है
  • इसे engineer की क्षमता की समस्या नहीं, बल्कि market competition की कमी और priorities की समस्या बताया गया
  • Stripe ने developer experience के लिए ऊँचा मानक स्थापित किया, लेकिन यूरोपीय regional payment networks (जैसे IRIS) को पूरी तरह support नहीं करता, इसलिए विकल्प कम हैं
  • जब तक Stripe स्तर का competitor नहीं आता, ऐसी quality समस्याएँ जारी रहने की संभावना है

तकनीकी सुधार का सुझाव

  • Viva.com को outgoing ईमेल में Message-ID header जोड़ना चाहिए
    • उदाहरण: Message-ID: <unique-id@viva.com>
    • अधिकांश email libraries इसे अपने आप generate करती हैं, और यह एक लाइन के बदलाव से ठीक हो सकता है
  • Google Workspace users को verification ईमेल सामान्य रूप से मिल सकें, इसके लिए तुरंत सुधार ज़रूरी है

RFC terminology और Google की policy

  • RFC 2119 के अनुसार
    • MUST: पूर्णतः अनिवार्य requirement
    • SHOULD: केवल विशेष कारण होने पर छोड़ा जा सकता है
    • MAY: पूरी तरह optional
  • Message-ID के SHOULD होने का कारण यह है कि कुछ client इसे server पर छोड़ देते हैं
  • Google spam रोकने के लिए इसे enforced requirement की तरह लागू करता है, और इस अर्थ में RFC से भी अधिक व्यावहारिक standard की भूमिका निभाता है
  • अगर Viva.com ने इसे जानबूझकर छोड़ा है, तो कम-से-कम “Google Workspace के साथ compatible नहीं” जैसी warning देनी चाहिए
    • बिना किसी सूचना के इसे चलाना SHOULD requirement की भावना के भी विरुद्ध है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-02-13
Hacker News की राय

  • Viva.com के verification email में Message-ID header नहीं था, यही मुख्य समस्या बताई गई
    RFC 5322 के section 3.6 के अनुसार “every message SHOULD have a Message-ID field” लिखा है, लेकिन SHOULD, MUST नहीं है, इसलिए क्या इसे ‘requirement’ कहना सही है — इस पर सवाल उठाया गया

    • समझाया गया कि SHOULD व्यवहार में लगभग अनिवार्य requirement जैसा ही है
      जब तक कोई खास वजह न हो, इसका पालन करना चाहिए; सिर्फ “झंझट लगता है” कोई अपवाद नहीं हो सकता
      पहले MUA अगर Message-ID के बिना mail भेजता था, तो server उसे अपने-आप जोड़ देता था, इसलिए इसे SHOULD लिखा गया था
      इससे जुड़ी बात RFC 6409 section 8.3 में साफ़ लिखी है
    • RFC2119 के मुताबिक SHOULD का मतलब है “कुछ खास हालात में इसे नज़रअंदाज़ किया जा सकता है, लेकिन उसके नतीजों को अच्छी तरह समझकर और सावधानी से फैसला करना चाहिए”
      Google ने इसे किस तरह समझा, यह स्पष्ट नहीं है
    • एक hosting company के postmaster ने कहा कि production environment में Message-ID वास्तव में ज़रूरी होता है
      test mail की बात अलग है, लेकिन live service mail में यह न हो तो spam filtering जैसी चीज़ों में दिक्कत आती है
      Message-ID का न होना अक्सर ढीले-ढाले custom sending system का संकेत माना जाता है
    • Message-ID technically mandatory नहीं है, लेकिन Amazon SES जैसी कुछ सेवाएँ मौजूदा Message-ID को overwrite कर देती हैं, इस पर भी नाराज़गी जताई गई
    • तकनीकी रूप से इसके बिना भी काम चल सकता है, लेकिन सामान्य email के रूप में classify होने के लिए यह लगभग ज़रूरी माना गया
      खासकर यह बात चौंकाने वाली बताई गई कि एक payment service ने Google Workspace जैसे बड़े mail service पर test तक नहीं किया

  • ESP (Email Service Provider) में काम कर चुके एक व्यक्ति ने कहा कि ज़्यादातर server software Message-ID के बिना आने वाले mail को reject कर देते थे
    Google जैसे बड़े recipient से आने वाले bounce को नज़रअंदाज़ करना कल्पना से बाहर बताया गया

    • व्यावहारिक दुनिया में standard से ज़्यादा user problem रोकना महत्वपूर्ण माना गया
      सामने वाला system irrational हो, तब भी user की परेशानी रोकने के लिए उसके हिसाब से चलना बेहतर है
    • Google Workspace को mail भेजना है तो Message-ID व्यवहार में MUST है
      अगर इसे जोड़ना नहीं है, तो साफ़ लिख देना चाहिए कि “Google Workspace users के लिए service उपलब्ध नहीं”
    • लेकिन ज़्यादातर कंपनियाँ ऐसी technical details में दिलचस्पी नहीं लेतीं, उनका रवैया बस “जल्दी service चालू हो जाए” वाला होता है
      Viva और Google दोनों इतने बड़े हैं कि कुछ ग्राहकों की समस्या पर ध्यान नहीं देंगे, ऐसा कहा गया
    • यह भी कहा गया कि यूरोपीय कंपनियों में शायद Google Workspace का उपयोग उतना बड़ा हिस्सा नहीं रखता हो

  • कुछ लोगों ने email के text/plain alternative part को बेहद खराब तरीके से भेजने वाली सेवाओं की भी शिकायत की
    जैसे text version में link ही न होना, या सिर्फ “यह plain text email है” जैसी बेकार सामग्री भेजना

    • notification में सिर्फ “cute line” दिखाने वाला plain text version सबसे ज़्यादा परेशान करने वाला बताया गया
      मज़ाक में कहा गया कि email client में HTML को AI से summarize करने का फीचर होना चाहिए
    • एक service ने तो plain text भाग में दूसरे customer की booking information तक शामिल करके भेज दी थी (Avis मामला)
    • किसी ने कहा कि उसने ऐसी implementation देखी है जो Lynx browser से HTML dump करके text/plain बनाती है, लेकिन यह वाकई कितना उपयोगी है, इस पर संदेह जताया गया
    • कुछ मामलों में text/plain में HTML source या CSS को ज्यों का त्यों डालते भी देखा गया

  • वित्तीय संस्थानों की तकनीकी अयोग्यता पर तंज कसने वाली टिप्पणियाँ भी थीं
    “Major European Payment Processor” को लगभग “Major European Incompetence Center” कहा गया

    • एक अन्य उपयोगकर्ता ने कहा कि यह बढ़ा-चढ़ाकर कही बात लग सकती है, लेकिन वास्तव में financial institutions की security हालत बहुत खराब रही है
      उदाहरण के लिए, Harland Financial Systems 2-byte XOR encryption इस्तेमाल करता था और key को connection की शुरुआत में plain text में भेज देता था
    • एक और उपयोगकर्ता ने अमेरिकी financial institutions के भ्रष्टाचार के उदाहरण (गलत approvals, बिना अनुमति account खोलना आदि) गिनाकर पूछा कि क्या यूरोप में भी हालात ऐसे ही हैं

  • Gmail से Fastmail पर गए एक उपयोगकर्ता ने Google की कड़ी spam filtering के प्रति कुछ हद तक सहमति जताई
    उसका कहना था कि Fastmail में spam और phishing mail ज़्यादा पहुँचते हैं

    • दूसरे उपयोगकर्ता ने कहा कि Message-ID automated mail के लिए व्यवहार में industry standard है, इसलिए Google की कार्रवाई अतिशयोक्तिपूर्ण नहीं लगी
      startup अक्सर default template ज्यों का त्यों इस्तेमाल करते हैं, जिससे mail phishing समझ लिया जाता है
    • सलाह दी गई कि समय के साथ Fastmail का spam filter सीख जाता है और बेहतर हो जाता है
    • एक पुराने Fastmail user ने मज़ाक में कहा कि कभी-कभार spam निकल आता है, लेकिन LinkedIn mail ही एकमात्र चीज़ है जो हमेशा पार हो जाती है
    • यह भी कहा गया कि Fastmail में समय-समय पर spam response धीमा पड़ जाता है, लेकिन कुल मिलाकर अनुभव अच्छा है

  • कुछ लोगों की राय थी कि RFC के हिसाब से Viva.com गलत है, लेकिन Google का SHOULD clause के आधार पर mail reject करना भी उचित नहीं है
    अगर spam की आशंका ज़्यादा है, तो उसे spam folder में भेजना चाहिए था; सीधे reject करना ज़्यादा सख्त कदम माना गया

    • इस बहाने यह भी कहा गया कि customer support team अक्सर समस्या को technical team तक पहुँचाने के बजाय रटे-रटाए जवाब दोहराती रहती है
    • एक insider अनुभव भी साझा किया गया कि support staff अगर समस्या स्वीकार कर ले, तो performance review में नुकसान हो सकता है, इसलिए वे बंधे होते हैं
    • एक निंदक राय यह भी थी कि email standards व्यवहार में कभी पूरी तरह काम नहीं करते, और लगभग हर rule असल में “SHOULD” ही है

  • सबसे गंभीर बात यह बताई गई कि Viva.com ने Google Workspace के साथ mail delivery समस्या को test तक नहीं किया

    • व्यंग्य में कहा गया कि असल में वे user signup failure के ज़रिए “real-time testing” कर रहे थे
      यह भी कहा गया कि समस्या शायद Google की तरफ़ के बदलाव से शुरू हुई हो, लेकिन monitoring का न होना उससे भी बड़ी समस्या है
    • इसके जवाब में यह तर्क भी आया कि “दुनिया की हर कंपनी Google Workspace तो इस्तेमाल नहीं करती”

  • यह सवाल भी उठा कि Viva.com को ऐसी समस्या का इतने लंबे समय तक पता कैसे नहीं चला
    कहा गया कि सामान्य mail software में ऐसी दिक्कत शायद आती ही नहीं; इसलिए misconfiguration की संभावना जताई गई
    SHOULD, MAY नहीं होता, और अगर आप इसे implement नहीं करते तो समस्या झेलने के लिए तैयार रहना चाहिए
    Google ने error message में कारण बता दिया, इसे उल्टा अच्छी बात माना गया

  • Message-ID को मूल रूप से Usenet से आया हुआ आवश्यक field बताया गया,
    और कहा गया कि email की threading, reply, archiving — सबमें इसकी ज़रूरत पड़ती है
    Message-ID का न होना मानो यह कहना है कि “न जवाब चाहिए, न कोई रिकॉर्ड रहना चाहिए”, इसलिए यह संदिग्ध व्यवहार लगता है

  • मूल पोस्ट में यूरोपीय कंपनियों के API quality पर की गई आलोचना के जवाब में,
    कुछ लोगों ने कहा कि यह किसी एक region की समस्या नहीं, बल्कि दुनियाभर के startups और financial institutions में दिखने वाला common pattern है
    बड़ी कंपनियाँ अक्सर API को side business की तरह देखती हैं, या regulatory compliance के लिए मजबूरी में चलाती हैं
    वहीं Stripe जैसी कंपनियों के लिए API lifeline है, इसलिए उनकी quality बेहतर होती है
    startups के पास resources कम होते हैं, इसलिए वे अक्सर “use करने में आसान API” से पहले “बस चलने वाला API” को प्राथमिकता देते हैं