Email is tough: Major European Payment Processor's Emails rejected by GWorkspace
A major European payment processor, Viva.com, found its verification emails rejected by Google Workspace for lacking a basic 'Message-ID' header, a 'SHOULD' not 'MUST' requirement in email RFCs. This incident sparked a debate on strict protocol enforcement versus practical deliverability and exposed the frustrations of working with legacy European fintech. Hacker News dove deep into email standards, the pragmatism of 'SHOULD' versus 'MUST', and the implications of platform giants shaping the internet's core protocols.
The Lowdown
A developer attempting to create an account with Viva.com, a prominent European payment processor, encountered an unexpected hurdle: their verification emails never arrived at his Google Workspace-hosted address. This seemingly minor issue quickly escalated into a technical deep dive, revealing a fundamental email compliance problem at Viva.com and raising broader questions about the state of European fintech infrastructure.
The core of the problem lay in Viva.com's outgoing emails lacking a Message-ID header, a field deemed 'SHOULD be present' by RFC 5322 since 2008. While the RFC specifies 'SHOULD' (recommended) rather than 'MUST' (required), Google Workspace's mail servers rejected these messages outright, preventing them from even reaching the spam folder. The author managed to circumvent the problem by using a personal @gmail.com address, which successfully received the verification email, highlighting Google's inconsistent enforcement across its different services.
- The author couldn't receive a verification email from Viva.com on their Google Workspace account, which was necessary to complete registration.
- Google Workspace email logs revealed the bounce reason: missing 'Message-ID' header, a field described as 'SHOULD be present' in RFC 5322 since 2008.
- A workaround involved using a personal
@gmail.comaddress, which successfully received the email, indicating Google's varying enforcement policies. - Viva.com's support dismissed the detailed bug report, stating the issue was resolved since the author eventually verified their email.
- The author questions the overall technical competency of the payment processor and the broader state of European business APIs, noting a lack of competitive pressure leading to subpar developer experiences compared to services like Stripe.
- The post concludes by offering a simple fix for Viva.com: generate a
Message-IDheader, which most email libraries do automatically.
This incident serves as a case study for the fragile nature of email deliverability, the friction between strict protocol enforcement and practical interoperability, and the ongoing struggle for high-quality technical infrastructure in certain markets.
The Gossip
Should vs. Must: RFC Reckoning
Commenters passionately debated whether Google was justified in rejecting emails for a 'SHOULD' requirement. Some argued that 'SHOULD' implies flexibility, making Google overly strict and non-compliant with the RFC's spirit. Others contended that while technically optional, the 'Message-ID' header is critical for modern email deliverability, especially for spam filtering, and its absence indicates poor email hygiene from the sender. The distinction between Google Workspace's strictness and personal Gmail's leniency further fueled the discussion.
Fintech Fails and Frustrating Support
Many in the HN community resonated with the author's frustration, sharing anecdotes of incompetence within financial institutions and beyond. They highlighted how seemingly basic technical flaws are common in fintech, often due to a lack of competitive pressure or antiquated systems. The dismissive support response from Viva.com was a particular point of contention, seen as a classic example of customer service failing to engage with genuine technical issues.
Email's Enduring Enigma
The discussion delved into the inherent 'toughness' of email as a protocol, acknowledging its complexity due to legacy cruft, spam concerns, and the dominance of a few large providers (Google, Microsoft). Many expressed that reliable email deliverability is a monumental task, often necessitating dedicated Email Service Providers (ESPs) rather than DIY solutions, and that core email functionality can be held hostage by the evolving and often opaque rules of major mail handlers.
Google's Gatekeeping & Market Power
A recurring theme questioned Google's motives and market influence. Commenters speculated that Google's stringent requirements, particularly for Google Workspace users compared to free Gmail accounts, could be seen as a tactic to exert control over the email ecosystem or even as anti-competitive. This perspective suggests that while technically justified in some ways, Google's actions contribute to a landscape where smaller providers struggle against the arbitrary power of tech giants.