Major European payment processor can't send email to Google Workspace users • Hacker News Board

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

#401

Post by Arnt » Fri, Feb 13, 2026, 2:03 PM UTC

SecretDreams wrote: post #246

Arnt wrote: post #142

Earlier quoted context omitted.

SHOULD is a requirement. It means that you have to do it unless you know some specific reason that the requirement doesn't apply in your case. "I don't want to" is not a valid excuse, "I don't see a reason to" isn't either. IIRC this particular rule is a SHOULD because MUAs often send messages without a Message-ID to their submission server, and the submission server adds one if necessary. https://www.rfc-editor.org/…

Should = internal target Must = external requirement I cannot fathom how you think should* would act as a requirement in any sense of the world.

If you read RFC 2119, you'll see that the definition of SHOULD includes the word must. Perhaps it's easier to understand if I rephrase it as: "If you understand the issue and its consequences, SHOULD means optional. If you don't, SHOULD is equivalent to MUST."

Message-ID has maybe half a dozen types of problem. If you know all of them, leaving it out is up to you.

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

#402

Post by atherton94027 » Fri, Feb 13, 2026, 2:27 PM UTC

geocar wrote: post #365

atherton94027 wrote: post #336

Earlier quoted context omitted.

Well, gmail does not manage usenet groups and mailing lists. Delivery status notifications are considered best effort so it wouldn't make sense to block messages for that case. Additionally, Gmail adds its own message identifier on every message (g-msgid) because it knows that message ids can not be trusted to be unique. Finally just calling me ignorant is the cherry on top – please try to keep things civil on here.

> Well, [google] does not manage usenet groups and mailing lists. They do. Sort of. Google used to nntp, and manages the largest usenet archive; They still have one of the largest mailing list servers in the world, and they still perform distribution on those lists via SMTP email. They still have all of the problems associated with it, as do lots of other mail/news/list sites still do that are a fraction of Google's…

> If it's something else, I'm sorry I just don't understand.

I'm trying to explain to you that you're speaking very authoritatively about how things were done 30 years ago but things have changed since then, Gmail won't even send a message non-delivery notification to non-DKIM hosts.

Same thing with the g-msgid I'm telling you about – google documented it explicitly as a unique identifier, see here for example: https://developers.google.com/workspace/gmail/imap/imap-exte...

So yeah, things changed.

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

#403

Post by SAI_Peregrinus » Fri, Feb 13, 2026, 2:37 PM UTC

Arnt wrote: post #163

opto wrote: post #156

Earlier quoted context omitted.

In a completely different field, navigating ships at sea, the Collision Regulations which define how people must conduct ships at sea, they use the words "Shall" and "May" to differentiate legal requirements and what may just be best practice. "Should" intuitively means something more like "May" to me

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.

I feel like "SHOULD" and "SHOULD NOT" are redundant. You end up having to assume someone else treated them as a "MAY". If you control all the endpoints in a private implementation you can just deviate from the standard & not implement a MUST, it's your private implementation. There's thus no difference in public implementations between "SHOULD" and "MAY", and no difference in internal implementations between any of the words. They are therefore redundant, requirements are either mandatory or optional, there's no middle.

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

#404

Post by zamadatix » Fri, Feb 13, 2026, 2:51 PM UTC

merlindru wrote: post #390

nerdsniper wrote: post #312

Earlier quoted context omitted.

> 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.

if you apply that logic every recommendation becomes mandatory no? if the alternative to [not doing a recommended thing] is [failure] then what's the difference between "should" and "must"? "we recommend you leave the keys in the ignition while putting your car in park" "or what?" "or your car may blow up, killing everyone inside. just a recommendation though!"

It makes more sense when you read all of the definitions together https://datatracker.ietf.org/doc/html/rfc2119:

- `MUST: This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.`

- `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.`

- `MAY: This word, or the adjective "OPTIONAL", mean that an item is truly optional.`

In practical terms:

- MUST: It's always a failure to do this. E.g. you MUST have some form of stored energy in your car for it to propel itself down the highway.

- SHOULD: If you don't do this, it's likely to cause failures unless you really know the situation is one of great exception and have thought about what else this change may affect. E.g. you SHOULD maintain a large distance between yourself and then next vehicle on the highway (an example of an exceptional case might be a standstill backup on the highway).

- MAY: This is something which is actually optional and has negligible impacts to successful operation if you do/don't. E.g. you MAY activate cruise control instead of always manually operating the accelerator.

For your car example as-is it'd probably best be MUST unless there is expectation one might reasonably consider their car exploding a valid scenario. In the real world where the car doesn't actually blow, it'd probably be that you MAY leave your keys in the ignition rather than SHOULD/MUST.

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

#405

Post by kbolino » Fri, Feb 13, 2026, 3:39 PM UTC

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.

text/plain != plaintext

This is about media types, not encryption.

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

#406

Post by geocar » Fri, Feb 13, 2026, 3:53 PM UTC

atherton94027 wrote: post #402

geocar wrote: post #365

Earlier quoted context omitted.

> Well, [google] does not manage usenet groups and mailing lists. They do. Sort of. Google used to nntp, and manages the largest usenet archive; They still have one of the largest mailing list servers in the world, and they still perform distribution on those lists via SMTP email. They still have all of the problems associated with it, as do lots of other mail/news/list sites still do that are a fraction of Google's…

> If it's something else, I'm sorry I just don't understand. I'm trying to explain to you that you're speaking very authoritatively about how things were done 30 years ago but things have changed since then, Gmail won't even send a message non-delivery notification to non-DKIM hosts. Same thing with the g-msgid I'm telling you about – google documented it explicitly as a unique identifier, see here for example: https…

[flagged]

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

#407

Post by gsck » Fri, Feb 13, 2026, 3:53 PM UTC

I dont think people fully realise how novel Stripe actually is.

The idea of capturing payments via an API itself isn't unique, but the fact that as a company Stripe is actually on average pretty competent. I've never had an issue with stripe on the integration side because that just works.

I work with a massive variety of payment gateways, I'd imagine more than most people on this site ever will, 90% of them suck. The big ones all suck, Stripe's "competitors" suck. They all have effectively the same API but the issues are organisational.

Stripe is a technology company, its technology is good, its approach to the end user (Technical people implementing it) is good. The rest are finance companies and you get all the slow to move, impossible to get through to bureaucracy that comes with it. Of course they didn't respond to the actually issue and said "You've already solved it" and then ignored the actual problem. These payment providers sell their services to business not developers or anyone with technical chops.

They wont care about these issues because your boss has already been sold on the product, the issues are very very unlikely to change their mind and it is now your problem to solve.

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

#408

Post by disgruntledphd2 » Fri, Feb 13, 2026, 4:37 PM UTC

gsck wrote: post #407

I dont think people fully realise how novel Stripe actually is. The idea of capturing payments via an API itself isn't unique, but the fact that as a company Stripe is actually on average pretty competent. I've never had an issue with stripe on the integration side because that just works. I work with a massive variety of payment gateways, I'd imagine more than most people on this site ever will, 90% of them suck. Th…

> The rest are finance companies and you get all the slow to move, impossible to get through to bureaucracy that comes with it.

Look, I 100% get what you're saying here, but it's not (entirely) the other companies fault. The financial sector is incredibly regulated, and they're required to have policies and procedures for everything which leads to a terrible, no good, sub par user experience.

Stripe has (so far) managed to avoid this, but if (when) they end up in the regulators cross-hairs they too will become like many other financial companies. I mean, I want to be wrong on this but I don't think I am.

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

#409

Post by shadowgovt » Fri, Feb 13, 2026, 4:39 PM UTC

golem14 wrote: post #324

shadowgovt wrote: post #189

Earlier quoted context omitted.

At scale, it's very hard to distinguish malicious intent from the simple consequence of being the largest operator in a space so any motion one makes makes waves. For what it's worth: having seen some of how the sausage is made, Google isn't particularly interested in screwing over a small reputable German provider. But they also aren't particularly interested in supporting such a provider's desire to route messages…

What does “not particularly good actors” mean in this context? Actors as in theater? Or “Bad actors” plotting evil things?

Actors in a theater. I have no reason to believe they were pretending to be upset because the were actually spies and knew what was going on before Snowden's reveals came out. They were as surprised as everyone else; the NSA wiretapping was done off-prem in cable that was privately owned (but stretched hundreds of miles and was, therefore, practically undefendable against compromise).

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

#410

Post by mothballed » Fri, Feb 13, 2026, 4:46 PM UTC

disgruntledphd2 wrote: post #408

gsck wrote: post #407

I dont think people fully realise how novel Stripe actually is. The idea of capturing payments via an API itself isn't unique, but the fact that as a company Stripe is actually on average pretty competent. I've never had an issue with stripe on the integration side because that just works. I work with a massive variety of payment gateways, I'd imagine more than most people on this site ever will, 90% of them suck. Th…

> The rest are finance companies and you get all the slow to move, impossible to get through to bureaucracy that comes with it. Look, I 100% get what you're saying here, but it's not (entirely) the other companies fault. The financial sector is incredibly regulated, and they're required to have policies and procedures for everything which leads to a terrible, no good, sub par user experience. Stripe has (so far) mana…

This is why a sane e-commerce platform should have routing through a bunch of different payment processors so they're not vulnerable to the regulator or regulatory officer anomalous behavior at any particular one.