Live data from Hacker News

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

atha.io

51–60 of 443 posts

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

#51
10 percent of the effort in building software compatibility with open source file specifications is dealing with knowing the specifications. 90 percent of the effort is dealing with errors in generated files by less worthy software programs.

The RSS spec is one way. RSS readers do a fine job of interpreting files done the right way. Publishers don’t always do a good job with publishing error free RSS files. So RSS readers devs have to anticipate all sorts of errors and conduct error handling to ensure RSS items are properly handled.

This is why companies want to keep their file format proprietary. Other devs can really do damage to the ecosystem and ruin the experience

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

#52
post #25
post #13

Earlier quoted context omitted.

The official definition of SHOULD per RFC2119: 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. Not sure how the people at Google interpreted this about the message-id

For producers, ignoring a SHOULD is riskier because it shifts the burden to every consumer. For consumers, ignoring a SHOULD mostly affects their own robustness. But here Google seems to understand it as a MUST... maybe the scale of spam is enough to justify it. Users are stuck between two parties that expect the other to behave.

> maybe the scale of spam is enough to justify it.

This is 100 percent the case, and why these things are this way.

If you wanted to make email two point oh, I dont think it would look a lot like what we have today.

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

#53
post #27

Earlier quoted context omitted.

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.

Yeah. I think email receiving is a game of exceptions… the email receivers (In the business world it’s essentially just MSFT and GOOG of course) answer to the addressees because they are the customer, and those customers will start to shriek if their inbox doesn’t receive “Important Messages.” But GOOG or MS have no leverage over the senders in this case so they just add an exception: “if IP range is just right and m…

Apple is another major player in the email receiving game for consumers. And they are awful, by far the worst of all the big providers. They do not send dmarc reports and they make it very difficult to tell why they accept some email and not others.

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

#54

Earlier quoted context omitted.

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

If Gmail rejects emails from your domain it is up to you to fix it. Google is not going to change, and enough of your users will be interacting with people on Gmail that you have to fix it. It doesn't help that Google has been pushing people away from running their own email and into Google's services by ever tightening what it accepts over the years. More than one person has given up on their email server because it…

An attempt no doubt to extenguish a standard google doesn't control

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

#55
post #21

Earlier quoted context omitted.

> My takeaway is that his test email bounced What test email? I see no mention of a test email in the blog post. The mail that bounced was the one with the verification link from Viva.

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

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

#56

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]

I wish I had your confidence in life

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

#57

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]

> I decided to dig into Google Workspace's Email Log Search to see what was happening on the receiving end.

It amazes me that you can read an article and draw the exact wrong conclusions

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

#58
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?

So I'm wondering a bit here - I've seen an implementation where emails to send only have html versions, but as part of the sending process the html is run through a Lynx browser process with the -dump command to get the plain text, which is included as the text/plain part of the email.

Is there actual value to this? e.g. Is the output of Lynx's text dump better for plain-text email clients than whatever they'd display for html emails?

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

#59

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]

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 sending a test email.

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

#60
post #46

Typically I'm a DIY type who loves tinkering and building... HOWEVER, I have learned the hard way to never apply that spirit to email. In Europe you see this stuff all the time with old school "IT" (what old industrial companies call tech) people balking at the prices of commercial API-based senders and email marketing ESPs. "Money to send emails in the cloud? HAH! Back at Siemens in 90s we were running millions of e…

Google is at least less arbitrary than Microsoft. Microsoft will decide an email is spam today, and tomorrow the exact same email is perfectly fine. I think Google relies more and more on sending IP and domain reputation rather than content.

Google regularly sends legitimate email to my spam folder.

Microsoft regularly sends legitimate emails from Microsoft to my spam folder.

Post reply on HN