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

31–40 of 443 posts

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

#31

Post by reeddev42 »

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 just shows up with a notification on their phone.

Obviously Telegram has its own limitations (smaller user base in the US, less formal). But for anything where you need reliable message delivery to people who opted in, messaging platforms have a massive advantage over email in 2026.

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

#33

Post by thatha7777 »

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…

You're totally right. I've updated the blog to reflect this. Thank you!

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

#35

Post by pilif »

citrin_ru wrote: post #28
ale42 wrote: 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

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…

On the other hand, by erroneously treating a SHOULD as a MUST, I would say that Google is the one who's not RFC-compliant

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

#36

Post by Waterluvian »

citrin_ru wrote: post #28
ale42 wrote: 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

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 are moving towards requiring it. In this case Google has decided it’s not an optional feature.

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

#37

Post by shevy-java »

The bigger issue here is that Europe depends way too much on the USA in so many areas. This is not good - you can be constantly blackmailed when you have people such as Trump in charge. I don't think the EU can be fixed, but at the same time I also think the less Europeans depend on outside factors (in particular the USA) the better. Canada kind of showed how to do it. Granted, Canada is also dependent on the USA in numerous ways and most of this is hard to fix (most Canadians live in the south aka close to the USA and trade is primarily done via the USA; security has also been largely outsourced onto the USA and so forth). The sooner people in Canada and Europe get moving away towards more independence from the USA, the better. And more cooperation would not harm either.

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

#38

Post by jeroenhd »

jandrese wrote: post #22
flerchin wrote: post #11

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…

Their @gmail.com servers accept the messages (as said in the post) so it's not a problem for 99% of Google users either.

If you choose to host your email with Google, it's up to you to fix your email delivery settings (or find a better provider) for your domain.

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

#39

Post by jmuguy »

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…

Most of that can be mitigated, or at least centrally managed, using an ESP like Mailgun or Sendgrid.

It is a pain in the ass though, coming from someone that had to dig their domain out of "low" reputation with Google Postmaster.

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

#40

Post by jagged-chisel »

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…

MUST means omission is unacceptable. SHOULD means MUST unless you have a good, well-reasoned excuse.
Post reply on HN