Live data from Hacker News

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

atha.io

261–270 of 443 posts

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

#261
post #42

I have some level of sympathy with Google here, which isn’t something I often say. I recently switched from Gmail to Fastmail and by and large I’m happy with it. But I’ve been surprised by the amount of spam and (particularly) phishing emails I get in a regular basis. Google might be too strict in its filtering but it does serve a legitimate purpose.

I've considered this switch. You're saying that previously gmail was dropping the emails, or they were landing in spam?

I switched from Fastmail to Gmail/Workspace a year ago. I think but cannot conclusively prove that Gmail drops Apple transaction emails on occasion ( like receipts ). But I also think Fastmail dropped other emails too.

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

#262

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.

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.

It amazes me people read that in this community and don't know for an email to bounce it means it didn't find an inbox. If it didn't find an inbox how did he check the logs?

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

#263

Earlier quoted context omitted.

[flagged]

EU doesn't require edits, what the hell? And nobody "decided to stop you" if you just hit the end of the 2 hour edit window. But go on, what's your tagline.

[flagged]

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

#264

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.

User is clearly mentally disturbed. Read his other comment: https://news.ycombinator.com/item?id=46992022 Social network is not good for the poor guy. I already regret replying to him in the first place but I cannot delete.

WTF you talking about? Rene, this is defamation and I'm probably going to take action because honestly, enough is enough. I'm fed up of folk like you who lack basic technical knowledge or any knowledge making up bullshit. Your hourly rate makes me like you have money to take.

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

#265

Earlier quoted context omitted.

[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

[flagged]

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

#266
post #203

Earlier quoted context omitted.

> isn't a valid excuse to reject a client either. Yes it absolutely is: https://www.rfc-editor.org/rfc/rfc2119 is quite clear. 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. If the client SHOULD do something and do…

That clearly means it’s not required. How does Google know whether or not the sender has a valid reason? They cannot know that so for them to reject an email for it means they would reject emails that have valid reasons as well.

> That clearly means it’s not required.

You and I have different definitions of "clearly"

It is not required for the protocol of one SMTP client sending one message to one SMTP server, but it is required for many Internet Mail applications to function properly.

This one for example, is where if you want to send an email to some sites, you are going to need a Message-ID, so you SHOULD add one if you're the originating mail site.

> How does Google know whether or not the sender has a valid reason?

If the Sender has a valid reason, they would have responded to the RFC (Request For Comments) telling implementers what they SHOULD do, rather than do their own thing and hope for the best!

Google knows the meaning of the word SHOULD.

> it means they would reject emails that have valid reasons as well.

No shit! They reject spam for example. And there's more than a few RFC's about that. Here's one about spam that specifically talks about using Message-ID:

https://datatracker.ietf.org/doc/html/rfc2635

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

#267
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 is a requirement. I once had a job where reading standards documents was my bread and butter. SHOULD is not a requirement. It is a recommendation. For requirements they use SHALL. My team was writing code that was safety related. Bad bugs could mean lives lost. We happily ignored a lot of SHOULDs and were open about it. We did it not because we had a good reason, but because it was convenient. We never justi…

Yes, except there seems to be a move on the best words from SHALL to MUST and from SHOULD to MAY. IANAL but I recall reading this in e.g. legal language guidance sites.

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

#268

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.

At least when you realize it, you are cured from any imposter syndrome you might have.

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

#269

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

You SHOULD follow the wording of the RFC, you MUST follow Google's interpretation of the RFC. That is the difference.

evidently they must not

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

#270
post #203

Earlier quoted context omitted.

> isn't a valid excuse to reject a client either. Yes it absolutely is: https://www.rfc-editor.org/rfc/rfc2119 is quite clear. 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. If the client SHOULD do something and do…

> If the client SHOULD do something and doesn't, and your server does not know why, you SHOULD disconnect and move on. That is not a rule. In this situation the server can reject any message if it wants to, and not doing a SHOULD tests the server's patience, but it's still ultimately in the "server wanted to" category, not the "RFC was violated" category.

[flagged]
Post reply on HN