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

281–290 of 443 posts

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

#281

Post by conductr »

drecked wrote: post #251
geocar wrote: 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.

How would the sender know the consequences of sending without the header? You shouldn’t assume anything here. As a sender, you should include it unless you’ve already worked out what the recipient is expecting or how it will be handled. Doing this with email is silly because the client is sennding to so many different servers they know nothing about so it’s basically a requirement to include it.

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

#282

Post by dsl »

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

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 standards requirement or you have a very specific edge case.

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

#283

Post by db48x »

saurik wrote: 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?

My favorite is when the plain text version is a bunch of css and html.

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

#284

Post by Alive-in-2025 »

aunderscored wrote: post #276
seb1204 wrote: post #267

Earlier quoted context omitted.

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.

RFC language is expmicltly defined in 2119[0]. Any other interpretation is incorrect. [0] https://www.rfc-editor.org/rfc/rfc2119

Thank you for that. So should is optional, people!

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

#286

Post by bnastic »

afavour wrote: 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.

Long time Fastmail customer. Let it learn a bit about your inbox. I barely see any spam these days that’s not been caught. Except LinkedIn, that somehow goes through

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

#287

Post by warkdarrior »

bojan wrote: post #202
looperhacks wrote: post #201

> This experience fits a pattern I keep running into with European business-facing APIs and services. Something is always a little bit broken. Documentation is incomplete, or packaged as a nasty PDF, edge cases are unhandled, error messages are misleading, and when you report issues, the support team doesn't have the technical depth to understand what you're telling them. I can definitely confirm that this is a commo…

While there is some truth in while you saying, I have to say that from my European perspective all the big American companies feel enormously bloated. For example, I've recently learned thats Atlassian has 13000 employees, and I have to ask myself, what do all those people do?

I bet Atlassian's email notifications never bounced.

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

#288

Post by warkdarrior »

youknownothing wrote: post #120

It used to be said that the reason the Internet evolved so well was because of the basic principle of "be strict when you send, but tolerant when you receive". Clearly Google has forgotten this.

That worked when the Internet participants were mostly benign. Nowadays you have to account for abusive participants (spammers, malware writers, etc., etc.).

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

#289

Post by wiredpancake »

eduction wrote: post #253

I’m sorry but in the context of a 50 year old technology like email, 2008 was yesterday. Gmail is in the wrong, you don’t get to just update the standard for email like it’s TikTok content or a Roblox update or whatever. Email was here long before Gmail and will be here long after Google abandons it. This is why I don’t use Gmail. Also, get off my lawn.

[dead]

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

#290

Post by jcelerier »

dsl wrote: post #282
BeetleB wrote: post #244

Earlier quoted context omitted.

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

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…

I just don't understand how you get from the text you pasted to "required". Nowhere does it say that anything is effectively required. Words have meaning.
Post reply on HN