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

121–130 of 443 posts

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

#121

Post by phicoh »

Waterluvian wrote: post #36
citrin_ru wrote: post #28

Earlier quoted context omitted.

You can argue that you not obligated to use message-id but if you don't use it you should blame only yourself that your messages are not accepted. In requiring message-id I would side with google (though in general I think they anti-spam is too aggressive and lacks ways to report false positives). Full RFC compliance (as in not only MUST but also SHOULD unless you have a very good reason) is the easiest part of makin…

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…

Typically, MUST means that if you don't do that then something will break at the protocol level.

SHOULD means that if you don't that, bad things are likely to happen, but it will not immediately break at the protocol level and during discussion in the IETF some people thought there could be valid reasons to violate the SHOULD.

Typically, IETF standards track RFCs consider the immediate effects of the protocol but often do not consider operational reality very well.

Sometimes operational reality is that a MUST gets violated because the standard is just wrong. Sometimes a SHOULD becomes required, etc.

Certainly for email, there is a lot you have to do to get your email accepted that is not spelled out in the RFCs.

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

#122

Post by bell-cot »

lokar wrote: post #108
hughw wrote: post #91

Postel’s Law would put the onus on Google to be forgiving in what it receives. Unsure how you could safely use a sender-created Message-Id for anything anyway.

That “law” if from a different time, before protocols like SMTP became adversarial. It assumed everyone was acting in good faith.

Yep. And even a world of perfect good faith, "forgiving in what you receive" has both costs and scaling problems - from researching what "spec" you'll need to design to, to customer service when the added complexity and permissiveness cause interesting stuff to happen.

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

#123

Post by nottorp »

thatha7777 wrote: post #98
Deukhoofd wrote: post #7

Might want to consider Adyen, which should support IRIS, the Greek instant payment system.

Thank you for the recommendation! That I couldn't sign up using a form and I had to "talk to their team" was a turn-off for my (extremely extroverted) self.

That usually means you can't afford it unless you have people working for you that do the 'talk to the team' thing.

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

#124

Post by pbhjpbhj »

basilikum wrote: post #78
reeddev42 wrote: post #31

Email deliverability is the reason I gave up on email entirely for my side project and built on Telegram instead. Setting up SPF, DKIM, DMARC, warming up a domain, monitoring reputation, dealing with bounces and complaints... all of that just to maybe land in someone's inbox. With Telegram you send a message via the Bot API and it arrives. 100% deliverability. No spam filters. No authentication chain. The message jus…

Unless you are running a more complex setup SPF, DKIM and DMARC really aren't that complicated. They are annoying and additional checkboxes you have to go trough that are hard to fully automate because they require access to DNS, but they are more busywork than difficult. Domain and IP reputation and all the other quirks of deliverability are much more of a headache. DMARC is setup, test and done. But deliverability…

I found it maddening that I couldn't whitelist a sender (MS Outlook web, Gmail); well I could, but they still blocked the messages.

In my case, it was reportedly (for MS) an IP associated with mine (same hosting provider) had previously been used to send spam.

My domain is decades old, never sent any spam, and I whitelisted it .. but nope, my host wasn't perfect.

This was some time ago now, but it looks like they've still not adopted proper whitelisting.

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

#125

Post by thatha7777 »

that_guy_iain wrote: post #16
flerchin wrote: post #11

Earlier quoted context omitted.

Interesting, your take away is that Google is the one with the bug here?

My takeaway is there is no bug. My takeaway is that his test email bounced because he didn't have the reputation Viva does. Emails are handled on a reputation basis, this is why we use email service providers like Sendgrid, Mailgun, Postmark, etc.

What test email?

https://atha.io/_next/image?url=%2Fstatic%2Fblog%2F2026%2Fvi...

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

#126

Post by thatha7777 »

PaulDavisThe1st wrote: post #59
that_guy_iain wrote: post #45

Earlier quoted context omitted.

[flagged]

Pretty certain that you're wrong. TFA shows an excerpt from the email log for his google workspace account, showing the bounce of email sent from viva.com. Then, TFA states that he switched "the account" (his viva.com account) from using his GWorkspace address to a personal @gmail.com address, and asked viva to send another verification email. That one arrived. At no point does TFA describe the author themselves send…

I've added a screenshot at the end of the blog post just to clarify that.

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

#127

Post by roysting »

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?

It's a broad question, but in many ways, very clearly yes, re. corruption of financial institutions, and to a far greater extent in many, albeit different ways.

Incompetence and corruption only slightly overlap in most cases, i.e., being competent at corruption is a very real thing. The incompetently corrupt, usually end up punished... and there are few and far between...as we all very well know.

The kind of schemes you mentioned are generally not going to be how "corruption" will manifest itself in European financial institutions, because although it is also difficult to speak in general across Europe since the EU has not yet subsumed democratic self-determination all across the continent yet, so there is wide variation; the competent corruption is largely in the form of money laundering and tax evasion, not lower level quantitative schemes that would quickly come to light because Europeans are also a lot more cognizant of money and value than Americans, so people are paying attention a lot more closely and will raise hell over a single cent, where Americans are known to have hundreds of dollars draining out of their pockets every month just alone on recurring payments for things they don't even use anymore and don't bother dealing with it.

What we all don't really seem to internalize as a human species, is the absolutely demonic type of pernicious nature of "banking", i.e., a kind of LotR, ring, that consumes you especially if you are weak... and human, or at least European civilization seems to frequently go through periods of immense weakness where things are going springily and everyone is dancing to the music the "bankers" are playing as they are pandering our pockets, and when they realize they could get away with that and all the pockets are plundered, they move on to plundering our homes, then our accounts, then they want to take our first born... "Banking" is like humanity's cocaine, the seemingly innocuous, feel good drug that will consume your soul if you do not rage and fight against that demon taking over aggressively. It's no coincidence that cocaine is so widely used by the most parasitic elements of European societies, especially in "banking"/finance in general.

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

#128

Post by ajross »

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…

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

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

#129

Post by thatha7777 »

that_guy_iain wrote: post #45
Johnny555 wrote: post #26

Earlier quoted context omitted.

It always amazes me how people can read a blog post like this one that has a clear description of the problem with a log excerpts demonstrating the problem, and then people will confidently make up a completely different scenario that was not mentioned at all and blame the problem on that.

[flagged]

Would you mind scrolling to the end of the post? Or, if you're in a hurry: https://atha.io/_next/image?url=%2Fstatic%2Fblog%2F2026%2Fvi...

https://support.google.com/a/answer/2618874?hl=en

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

#130

Post by thatha7777 »

bn-usd-mistake wrote: post #55
that_guy_iain wrote: post #44

Earlier quoted context omitted.

So you think he had access to Viva's email servers to see the response? No, he clearly tested it himself and used his credentials to send it.

The log line is from Google Workspace which exposes it to its customers for incoming mail

Thank you! I added a screenshot of the Google Workspace Admin log screen... just becuase.
Post reply on HN