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

231–240 of 443 posts

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

#231

Post by eli »

tracker1 wrote: post #222
eli wrote: post #175

Earlier quoted context omitted.

Is the idea that you could decide from the envelope whether you want to even bother fetching the message? Besides that I'm not sure I see the advantage

You have to have a working mail server attached to a domain to be able to send mail... that's the big part. Right now, email can more or less come to anywhere from anywhere as anyone. There are extensions for signing connections, tls, etc... but in general SMTP at it's core is pretty open and there have been efforts to close this. It would simply close the loop and push the burden of the messages onto the sender's sy…

Like it proves you have the ability to receive mail at the domain you're sending from? I feel like SPF/DKIM already does this

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

#232

Post by 13415 »

shadowgovt wrote: post #189
13415 wrote: post #86

Earlier quoted context omitted.

Does it even matter when in reality it's more likely that this is intentional anti-competitive behavior by Google? They once made all emails from my very reputable small German email provider (a company that has existed and provided email services long before Google existed) go into a black whole - not bounce them back or anything like that, mind you, their servers accepted them and made them disappear forever. I was…

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…

Thanks for this reply full of interesting information! These kind of comments are what I like about HN.

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

#233

Post by x0x0 »

toomuchtodo wrote: post #216
leansensei wrote: post #165

Earlier quoted context omitted.

...and you'd be wrong.

For now, but with EU digital sovereignty efforts in full swing, it's possible this changes over time. More so if the EU uses regulation to dissuade the use of US Big Tech products and services.

... which is irrelevant to the demonstrated and shocking incompetence of being unable to deliver either to the #1 or #2 inbox for businesses in the EU?

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

#234

Post by thesuitonym »

fosron wrote: post #61

Worked on an ESP. We had a couple of server software we used on low-level for sending. None of them would accept the message without a Message-ID. But even if you have a super-custom, SMTP-injecting service built, how can you ignore all of these bounces from a provider thats likeliest to be the major one you are sending to? Unthinkable. I would not like to have business with such a payment provider.

> how can you ignore all of these bounces from a provider thats likeliest to be the major one you are sending to?

This is the major issue that most of the discussion is missing. It doesn't matter how you want to interpret the word SHOULD, if you want to send to google workspace, you MUST include a message-id. It's not like this is some fly-by-night server with 12 clients.

If you absolutely and completely don't want to include the message-id, then you need to have a warning that your service can't be used by Google Workspace customers. This used to be common practice, blocking communication to servers that behaved badly, and I sort of wish we'd bring it back.

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

#235

Post by Brian_K_White »

spongebobstoes wrote: post #43
Waterluvian wrote: post #36

Earlier quoted context omitted.

What is the point of SHOULD then? (No seriously, I’m asking; are there examples of where it’s actually different from a MUST)? Also this reminds me of something I read somewhere a long time ago: when specifying requirements don’t bother with SHOULD. Either you want it or you don’t. Because if it’s not a requirement, some people won’t implement it. I guess the one time it’s good is if you want an optional feature or a…

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 all, and has "should" is that it's useful and helpful and good to include, all else being equal.

But by the very definition itself, no people require it. No people are allowed to require it.

Any that do, are simply violating the spec.

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

#236

Post by Brian_K_White »

jagged-chisel wrote: post #40
Waterluvian wrote: post #36

Earlier quoted context omitted.

What is the point of SHOULD then? (No seriously, I’m asking; are there examples of where it’s actually different from a MUST)? Also this reminds me of something I read somewhere a long time ago: when specifying requirements don’t bother with SHOULD. Either you want it or you don’t. Because if it’s not a requirement, some people won’t implement it. I guess the one time it’s good is if you want an optional feature or a…

MUST means omission is unacceptable. SHOULD means MUST unless you have a good, well-reasoned excuse.

Incorrect. Not required is not required. You do not need to supply rationale or get agreement by anyone else that your reasons are good in their opinion and not just in your opinion.

Should just means the thing is preferred. It's something that is good and useful and helpful to do.

That is not "must unless you can convince me that you should be excused".

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

#237

Post by zos_kia »

ryandrake wrote: post #177
oasisbob wrote: post #64

Earlier quoted context omitted.

With a broad statement like this, I would usually just suggest this is inflammatory and surely overstated. However, I've also worked at a financial institution which used core systems by Harland Financial Systems. Their "encryption" for data in transit from teller workstations to the core system was just a two byte XOR, and they sent the key at the beginning of the connection! Was so unbelievable to be able to crack…

The biggest disappointment in my 30 years of adulting has been how much absolute, shameless incompetence is out there in the workforce. When I was a kid, I naively thought that adults were smart and knew what they are doing. Then I got into industry and saw so many people just outright bluffing for 8 hours a day before going home, day in and day out. It's amazing that society even functions at all.

I think that's actually an interesting feature of society as a macro system. It is very fault tolerant, which is frustrating for any power user but without which the system as a whole would not function at all.

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

#238

Post by askldfhalkdfh »

thayne wrote: post #113

> Who's in the right I don't think either are. The payment processor should be sending it, but, at least according to the RFC, it is incorrect to reject an email that doesn't have it. I suspect the reason it is SHOULD, and not MUST is for backwards compatibility with software that predates the RFC that adds the message-id header. Maybe there is a correlation between missing that header and being spam, but then it sho…

It's not necessarily the support person's fault. I worked in support way back when. There were some long-standing issues that needed only minor work to fix that engineering management didn't get, didn't care about or just wouldn't prioritize. Engineers weren't free to work on what wasn't prioritized. Acknowledging a problem and leaving the ticket open doomed to be unsolved forever negatively affected my performance rating. I had to respond with this sort of cheery everything's fine message and write it off as a customer issue, even though I didn't believe it.

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

#239

Post by toomuchtodo »

x0x0 wrote: post #233
toomuchtodo wrote: post #216

Earlier quoted context omitted.

For now, but with EU digital sovereignty efforts in full swing, it's possible this changes over time. More so if the EU uses regulation to dissuade the use of US Big Tech products and services.

... which is irrelevant to the demonstrated and shocking incompetence of being unable to deliver either to the #1 or #2 inbox for businesses in the EU?

Helps justify moving away from them I suppose.

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

#240

Post by josephg »

stackskipton wrote: post #155
L_226 wrote: post #150

Earlier quoted context omitted.

As someone who does systems engineering, the only valid requirements include the word "shall".

As someone else who does System Engineering, when dealing with ancient protocols, "shall" is extremely difficult barrier to get over since there is always ancient stuff out there and there might be cases not to do it, esp if it's internal communication. "SHOULD" is basically, if you control both sides of conversation, you can decide if it's required looking at your requirements. If you are talking between systems whe…

> … when dealing with ancient protocols

I’m doing some work with an email company at the moment. The company has been in the email space for decades. Holy moly email is just full of stuff like this. There is an insane amount of institutional knowledge about how email actually works - not what the specs say but what email servers need to actually do to process real emails and deal with real email clients and servers.

The rfcs try to keep up, but they’re missing a lot of details and all important context for why recommendations are as they are, and what you actually need to do to actually process real email you see in the wild. (And talk to the long tail of email software).

This conversation makes me think about cornering some of the engineers with a microphone. It’d be great to talk through the specs with them, to capture some of that missing commentary.

Post reply on HN