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

311–320 of 443 posts

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

#311

Post by spongebobstoes »

Brian_K_White wrote: post #235
spongebobstoes wrote: post #43

Earlier quoted context omitted.

SHOULD generally means: some people might require it. implement it for best results backward compatibility makes it hard to add MUST. using SHOULD is a good alternative

"SHOULD generally means: some people might require it." No it absolutely does not mean that. It means, by explicit definition which is right here, that text is exactly that definition, that no one requires it. They can't require it, and still be conforming to the spec or rfc. That's the entire point of that text is to define that and remove all ambiguity about it. It's not required by anyone. The reason it's there at…

the spec doesn't include an obligation to deliver your mail. it parses fine, and is rejected by the larger system

> the full implications must be understood and carefully weighed

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

#312

Post by nerdsniper »

jcelerier wrote: post #290
dsl wrote: post #282

Earlier quoted context omitted.

Maybe the standards documents you are used to differ from RFCs, but here is the official language: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. SHOULD is effectively REQUIRED unless it conflicts with another stan…

I just don't understand how you get from the text you pasted to "required". Nowhere does it say that anything is effectively required. Words have meaning.

> the full implications must be understood and carefully weighed before choosing a different course.

In this case, the full implication is that your email might be undeliverable. "Should" indicates that the consequences for this fall on the entity that is deviating from the thing they "should" be doing.

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

#313

Post by dathinab »

yndoendo wrote: post #80
basilikum wrote: post #10

With fintech that surprises me not the slightest bit. Financial institutions are filled to the brim with unbelievably incompetent people. A large part of it is probably willful ignorance, too. It's often truly staggering that a financial company I interact with in day to day live is even able to exist. That's until I remember that all the others are just as incompetent. "Major European Payment Processor" really just…

There is plenty amount of incompetence in FAAMG. Notepad .... Do Europe financial institutions have the same level of corruption as the USA? Such as a credit card company authorizing credit card transactions with incorrect expiration date to maximum profit, Bank of America? Or opening new accounts without consumer consent, Wells Fargo?

somewhat, but the question is to broad

it differs by country (EU gives countries some similar overlapping laws, but they still are distinct countries with a lot of different practices and different laws in many many ways.)

and it differs by severity

E.g. deutsche bank has become notorious to appear in most large scale bank scandals _in the US_ as a "German Representative". They also repeatedly get into trouble for relations to money laundering operations and other issues. At the same time they are the Bank which has to give you a (expensive but not completely absurd priced) bank account no matter your credit score, criminal history etc. and is the bank you mostly likely have a escrow account parking money if the person who gets it "if you mess up" is the state/local government (like e.g. in some long term visa context).

In general banks move very slow, including with software protocol updates/changes. And that isn't just the case in the EU AFIK. Actually some of the most crazy cases of "old software" I have seen in "the west" where as far as I remember in the UK and the issue was that it was deeply fundamentally impossible for them handle a lot of non English names correctly, like in 2017~2020 or so. Through at least they still could use the bank, just with a crippled/en-ified name. Funnily the same but worse (as in not working at all) I have heard about Japan banks, where they had(have?) really big issues if you have a middle name.).

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

#314

Post by zephen »

Alive-in-2025 wrote: post #284
aunderscored wrote: post #276

Earlier quoted context omitted.

RFC language is expmicltly defined in 2119[0]. Any other interpretation is incorrect. [0] https://www.rfc-editor.org/rfc/rfc2119

Thank you for that. So should is optional, people!

> So should is optional, people!

Only once you have satisfied:

> but the full implications must be understood and carefully weighed before choosing a different course.

In other words, you better have a damn good reason for deciding not to do it.

And (possibly even more to the point), you must decide not to do it, rather than simply throwing code at the wall until most emails make it through unscathed.

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

#315

Post by zephen »

shakna wrote: post #299
zdragnar wrote: post #295

Earlier quoted context omitted.

[flagged]

No, its not a "required"... It means someone may have reasons not to use something, and so spec implementors need to allow for circumstances where it is not present. Those reasons can be anything. Legal, practical, technological, ideaological. You don't know. All you know is not using it is explicitly permitted.

> You don't know. All you know is not using it is explicitly permitted.

In theory, if they are truly following the specification, you know they thought hard about all the consequences.

I think the pushback in the comments comes from the commonsense feeling that this... didn't happen here.

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

#316

Post by dathinab »

afavour wrote: post #42

I have some level of sympathy with Google here, which isn’t something I often say. I recently switched from Gmail to Fastmail and by and large I’m happy with it. But I’ve been surprised by the amount of spam and (particularly) phishing emails I get in a regular basis. Google might be too strict in its filtering but it does serve a legitimate purpose.

> Google might be too strict in its filtering

they are, but not in this case

Message-Id being basically required for _automated_ mails (very similar mail send to a lot of people) requiring Message-Id is a de-facto industry standard. Sure some providers don't care and some might make it just more likely that your mail ends up in spam. But this could have happened with pretty much any mail provider widely used by companies.

much more funny (/s) is if you start out in a startup and still use the default template for password reset/on-baording links of a widely used system (e.g. Keycloak) and it turns out multiple larger but "cheap" phishing campaigns did the same and now MS/Google and other suspect you are running a phishing operation

or when you use a local data center and can't send mails to MS/Outlook anymore because it turns out someone did some legal questionable things on them and MS wanted the personal information to be handed over _without court order or any ongoing legal proceeding against this people_ and they didn't hand it over (partially because they legally aren't allowed to...) and MS decided to retaliate by permanently blacklist the IPv4 range of that data center(s) which just happen to locally compete with Azure while self hosted mails competes with Outlooks...

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

#317

Post by dathinab »

> This experience fits a pattern I keep running into with European business-facing APIs and services

honestly, it's a pattern I have been running into with many start ups, fintech, banks and some other places _no matter where_.

It also often makes sense. For many large orgs (e.g. Banks) this APIs are often a side business, sometimes one they don't want but have to have for compliance (or market pressure). But for strip it's their live blood.

And many startups (like actual start ups, not 200 man companies running by investor money) often simply don't have the resources to prioritize a "very nice to use API".

Lastly API design which is both nice to use and stable for existing integrations is surprisingly hard to get right (if you don't have some senior engine prioritizing it very highly and forcing it being kept prioritized; Or a surprisingly "clean"/"clear" use case.).

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

#318

Post by hermanzegerman »

dwedge wrote: post #213
saurik wrote: post #12

My pet peeve are services that go out of their way to include a text/plain alternative message part but send something useless, such as the message without the key link. One time I seriously ran into a service just send a short one-sentence note along the lines of "this is a plain text email" as the plain text part. If you don't want to support plain text, maybe just don't send the alternative part?

I had one who sent me the booking details of another client in the plaintext part. I reported it to them nearly a year ago and they didn't reply, so screw anonymity, it was Avis.

Then report it to your government authority in charge of GDPR Enforcement. They suddenly will care very much about it

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

#319

Post by vel0city »

jcelerier wrote: post #290
dsl wrote: post #282

Earlier quoted context omitted.

Maybe the standards documents you are used to differ from RFCs, but here is the official language: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. SHOULD is effectively REQUIRED unless it conflicts with another stan…

I just don't understand how you get from the text you pasted to "required". Nowhere does it say that anything is effectively required. Words have meaning.

You should wear sunscreen to the beach. Its recommended as a good way to prevent sunburn. However, the beach police aren't going to come get you for not wearing it. You just might get a sunburn if you don't plan accordingly with other sun countermeasures.

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

#320

Post by hermanzegerman »

ajross wrote: post #226
jonathanstrange wrote: post #178

Earlier quoted context omitted.

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

If you have a client app that you think is reliably filtering spam, then to be blunt: you aren't receiving any spam, at least to first approximation. My stack of stuff on my three decade old personal account has a 95%+ hit rate (something I might naively be tempted to label as "reliably filtering spam"), and I see see more spam than signal in the inbox. GMail, on the other hand, is damn close to 100%. And it does it…

But GMail is accepting the Mails from his payment processor? It's just Google Workspace that won't
Post reply on HN