Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Major European payment processor can't send email to Google Workspace users

atha.io

Post reply on HN
Print view View original

191–200 of 443 posts

Re: Major European payment processor can't send email to Google Workspace users

#191

Post by shadowgovt »

davoneus wrote: post #138
FactolSarin wrote: post #93

Earlier quoted context omitted.

Google is rejecting it to ensure incoming messages aren't spam. SHOULD means "you should do this unless you have a really, really good reason not to." Do they have a good reason not to? It doesn't seem so, meaning Viva is in the wrong here.

No, SHOULD is defined in the RFC, not by colloquial usage. Google is on the wrong, regardless of their "safety" intent. After all, linguistics is full with examples of words that are spelled the same, but have different meaning in different cultures. I'm glad the RFC spelled it out it for everyone.

if Google's choices are protecting users, they can't be in the wrong. That's the reality of a shared communications infrastructure regardless of what the docs say.

When the docs disagree with the reality of threat-actor behavior, reality has to win because reality can't be fooled.

Re: Major European payment processor can't send email to Google Workspace users

#192

Post by atherton94027 »

shadowgovt wrote: post #186
Arnt wrote: post #158

Earlier quoted context omitted.

Hearsay has it that the reason is spam. Spam messages are said to have massively higher chances of minor RFC violations when they arrive at the destination server.

Most of the time, in my experience, when one encounters a situation like this in Internet tech (i.e. "why is this suggestion treated like a hard requirement?"), this is the answer: "because attackers found a way to exploit the lack of the suggestion's implementation in the wild, so it is now a hard requirement." The standards, to my observation, tend to lag the CVEs. Side-note: If someone has built a reverse-database…

How is not having a message-id a security risk? It seems that Gmail is being pedantic for no reason

Re: Major European payment processor can't send email to Google Workspace users

#193

Post by shadowgovt »

jonathanstrange wrote: post #178
ajross wrote: post #128

Earlier quoted context omitted.

Exactly. This minutiae is all so weird. Email as a formal specification does not work , and the industry as a whole has accepted that for decades now. It's not possible to filter spam from valid traffic without applying a truckload of heuristics and leveraging an ever growing set of auxiliary signals (SPF, DKIM, yada yada). To wit: basically everything in this world is a "SHOULD", at best. The rules are a conversatio…

Then why does my email program reliably distinguish spam from ham without any server-side filtering involved?

I'm just speculating, but probably because you're on an email provider that isn't a big enough target to worry about the persistent threat-actor model.

Google is a big enough target to justify spending the resources on dedicated attacks against their infra. Other providers may simply get less spam because their email domain shows up less often in the sources attackers use to pick targets.

Re: Major European payment processor can't send email to Google Workspace users

#194

Post by shaan7 »

s17n wrote: post #94
st_goliath wrote: post #9

> Viva.com's outgoing verification emails lack a Message-ID header, a requirement that has been part of the Internet Message Format specification (RFC 5322) since 2008 > ... > `Message-ID` is one of the most basic required headers in email. Section 3.6. of the RFC in question ( https://www.rfc-editor.org/rfc/rfc5322.html ) says: +----------------+--------+------------+----------------------------+ | Field | Min | Max…

The reason that European tech sucks is that people in Europe are open to such arguments. If an engineer in the US started talking about SHOULD vs MUST, some PM would just give them that "what the fuck did I just listen to" face, spend the next few minutes gently trying to convince them that the customer experience matters more than the spec, and if they fail, escalate and get the decision they want. For example, why…

Well the current US Administration would agree - the law doesn't matter, we need to be "pragmatic" and do what we think is right. Rules be damned.

Once you deviate a bit from the standard, you're down a slippery slope. Its not that difficult to use pragmatism to justify wrongdoing.

Re: Major European payment processor can't send email to Google Workspace users

#195

Post by [deleted] »

st_goliath wrote: post #9

> Viva.com's outgoing verification emails lack a Message-ID header, a requirement that has been part of the Internet Message Format specification (RFC 5322) since 2008 > ... > `Message-ID` is one of the most basic required headers in email. Section 3.6. of the RFC in question ( https://www.rfc-editor.org/rfc/rfc5322.html ) says: +----------------+--------+------------+----------------------------+ | Field | Min | Max…

[deleted]

Re: Major European payment processor can't send email to Google Workspace users

#196

Post by shadowgovt »

ejpir wrote: post #79
camgunz wrote: post #32

The most damning thing about this is they didn't test their email infra w/ Google Workspaces. Imagine what else they didn't test.

yeah, because the whole world uses Google workspaces, right /s

No, just over 6 million paying business customers.

But hey, if you're in a business domain where categorically leaving 6 million potential clients-who-are-demonstrated-to-spend-on-things isn't an issue? One fewer thing to worry about, right? ;)

Re: Major European payment processor can't send email to Google Workspace users

#197

Post by prerok »

patmorgan23 wrote: post #183
Arnt wrote: post #163

Earlier quoted context omitted.

Happily, the meanings in RFCs are clearly specified, see https://www.rfc-editor.org/rfc/rfc2119 . Note "the full implications must be understood and carefully weighed before choosing a different course". Gmail and the other big hosters have full-time spam teams who spend a lot of time weighing implications, so I assume the implications of this was weighed.

And EVERY rfc has a paragraph talking about rfc 2119 in the preamble.

I guess that's why nobody reads it. /s

Re: Major European payment processor can't send email to Google Workspace users

#198

Post by looperhacks »

hn_go_brrrrr wrote: post #81
ejpir wrote: post #79

Earlier quoted context omitted.

yeah, because the whole world uses Google workspaces, right /s

That and MS Office are pretty darn popular. Not the whole world, but a very decent percentage of your users.

If I were to test an email delivery system, I would test Gmail. I probably wouldn't test Google Workspaces, because I'd (wrongly) assume that they work the same.

Re: Major European payment processor can't send email to Google Workspace users

#199

Post by PunchyHamster »

st_goliath wrote: post #9

> Viva.com's outgoing verification emails lack a Message-ID header, a requirement that has been part of the Internet Message Format specification (RFC 5322) since 2008 > ... > `Message-ID` is one of the most basic required headers in email. Section 3.6. of the RFC in question ( https://www.rfc-editor.org/rfc/rfc5322.html ) says: +----------------+--------+------------+----------------------------+ | Field | Min | Max…

> That says SHOULD, not MUST, so how is it a requirement?

Battle with spam has been for long part just trying to algorithmically fingerprint the scam bots and reject the message if it looks like it wasn't sent by "real" mail server/client.

So a lot of things that are optional like SPF/DKIM are basically "implement this else your mail have good chance of being put into spam automatically".

Re: Major European payment processor can't send email to Google Workspace users

#200

Post by j1elo »

> For viva.com's engineering team, in case this reaches you: [...]

That's too kind of you, but on the other hand it really doesn't solve the issue of bad priorities and lack of overall Quality. Some engineer might log a couple hours fixing a Level 3 severity bug, emails will start working better, but the poor (or at the least, dubious) backwards technical stewardship (or lack of it) will keep going on inside the company, unnoticed from outside (until something bad eventually happens to some client)

Post reply on HN