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

341–350 of 443 posts

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

#341

Post by tempestn »

I've often found when receiving a clueless support response like this, it can be effective to just follow up with a polite request to forward the ticket to an engineer or developer. Usually the front-line csr simply hasn't understood the issue. In this case I would say something like,

"Yes, I managed to work around the issue by switching to my personal email address, but this bug is still preventing me from using my work email domain. If you could please forward the error log I included to a developer, it should help them resolve the issue. Thank you."

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

#342

Post by allarm »

HDThoreaun wrote: post #327
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…

This very clearly says that SHOULD is not effectively REQUIRED at all, and is fact nothing more than RECOMMENDED. Really not sure how you misinterpreted this so badly

You should read it again.

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

#343

Post by andmarios »

A quick search for their developer support revealed they accept submissions via GitHub issues for their API. Perhaps try there? https://developer.viva.com/get-support/

Sometimes you have to get creative to reach out to a company's engineering department...

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

#344

Post by fergie »

> The reason Message-ID is SHOULD rather than MUST? Mail clients

> sometimes send messages without one to their submission server, which

> adds it on their behalf. As for why Google enforces it anyway:

> spam. Messages with minor RFC violations are far more likely to be

> spam, so rejecting them is a reasonable heuristic. In practice, Google

> and Microsoft have become the de-facto standards bodies for email —

> what the RFCs say matters less than what their servers accept.

Surely the problem is on Google's end? And a metaproblem is that we are allowing corporations to change or ignore standards for critical infrastructure?

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

#345

Post by bossyTeacher »

b00ty4breakfast wrote: post #153
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…

I know you're looking for "pedant points" but the specification generally take a backseat to implementation. If Message-ID is expected out here where the rubber meets the road, then you are the squeaky wheel in this scenario for not including it.

> the specification generally take a backseat to implementation.

And we should be raising hell for it. Should never happen. Using your popularity to violate protocol should be not be tolerated

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

#346

Post by that_guy_iain »

fergie wrote: post #344

> The reason Message-ID is SHOULD rather than MUST? Mail clients > sometimes send messages without one to their submission server, which > adds it on their behalf. As for why Google enforces it anyway: > spam. Messages with minor RFC violations are far more likely to be > spam, so rejecting them is a reasonable heuristic. In practice, Google > and Microsoft have become the de-facto standards bodies for email — > what…

The email landed in the spam folder. A bounced email means it didn't find the inbox. If it didn't find an inbox there would be no log for him to check. Technical knowledge of emails and what the terms mean out him instantly as a liar. The fact this is still up on the front page is an embarrassment for the tech community in my opinion.

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

#347

Post by wartijn_ »

allarm wrote: post #342
HDThoreaun wrote: post #327

Earlier quoted context omitted.

This very clearly says that SHOULD is not effectively REQUIRED at all, and is fact nothing more than RECOMMENDED. Really not sure how you misinterpreted this so badly

You should read it again.

Are you recommending they read it again or requiring it?

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

#348

Post by sigseg1v »

HDThoreaun wrote: post #327
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…

This very clearly says that SHOULD is not effectively REQUIRED at all, and is fact nothing more than RECOMMENDED. Really not sure how you misinterpreted this so badly

It's not required but they need to understand the implications. In this case the implication is that Google drops the mail. So clearly they didn't understand the implications.

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

#349

Post by that_guy_iain »

Dylan16807 wrote: post #296
that_guy_iain wrote: post #263

Earlier quoted context omitted.

[flagged]

[flagged]

> You don't have the right to complain to random websites without punishment. And nobody punished you. And "ability to redress" is something you still have. And there are no damages.

Well, you see Dang aka Daniel edited the settings on my account to stop me replying, or that's what I've heard, and pointing out the absolute lie that the blog post is. And that did hamper my ability to redress and people have been lying about me so there are damages. But even if it's just rate limiting that hampers my ability especially since it's been optimised heavily for high traffic so there is no technical reason for it since it's a file-based datastore.

> You brought it up. Though it's pretty obvious you're a liar.

I said someone there should know. I didn't say everyone should know. I clearly made it quite clear it was insider knowledge. This is what is known as a flex. I want to tell you my tagline because it's awesome but you can just call me a keyboard warrior.

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

#350

Post by azernik »

BeetleB wrote: post #301
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…

Nope, it's exactly what it says: RECOMMENDED. Any time any document (standards or otherwise) says something is recommended, then of course you should think it through before going against the recommendation. Going from their verbiage to: > SHOULD is effectively REQUIRED unless it conflicts with another standards requirement or you have a very specific edge case. is a fairly big leap.

"The full implications must be understood and carefully weighed before choosing a different course." (emphasis mine)

i.e. you are required to have a good reason not to do it.

Post reply on HN