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

171–180 of 443 posts

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

#171

Post by OkayPhysicist »

kotaKat wrote: post #29

Sudden realization that one of my American banks must be having email problems with this too because I use a Google custom email and recently got an in-app notification from my bank saying "we're unable to email you" (and a letter) yet my email works perfectly fine... switching to consumer gmail worked.

Do you actually not receive their emails? Fidelity uses tracker dots to check email receipt, which drives me nuts, because like any sane person I don't allow emails to load images without damn good reason. My brokerage should not be sending me cute dog photos, thus I have no need of their images.

So they send me an email, send me another email saying they can't reach me by email, then mail me a letter with the same content as the original letter, and mail me an additional letter saying they can't reach me by email.

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

#172

Post by pmontra »

If a business like that doesn't get its emails delivered, it will slowly go out of business. Merchants will find another processor that is able to deliver emails to every inbox. That is, Google could be less picky, but the company with a problem at hand is Viva.

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

#173

Post by fmbb »

FactolSarin wrote: post #93
pilif wrote: post #35

Earlier quoted context omitted.

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

Google is rejecting it to ensure incoming messages aren't spam. SHOULD means "you should do this unless you have a really, really good reason not to." Do they have a good reason not to? It doesn't seem so, meaning Viva is in the wrong here.

Spam senders don’t have pseudorandom number generators?

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

#174

Post by Avamander »

pyrale wrote: post #90
mbreese wrote: post #69

Earlier quoted context omitted.

I think it's the latter. But, in either case, you're right in that you get the same result. Now, let's assume that if it is the latter (it's spam related), and Google were to accept the message, but then internally bin the message, it would be worse. At least in this case, they are bouncing the message. Because of this, the sender is at least aware that the message wasn't delivered. Also, the author was able to get t…

> Also, the author was able to get their mail delivered to a personal gmail.com address. The issue was with a Google Workspace custom email domain. This further makes me think of this as a security/spam related issue. Google is clearly capable of processing the message without a Message-id, they are just refusing for business customers. That's the annoying part to me. An email is an email. By applying different rules…

Other anti-spam implementations also punish the lack of Message-ID. There are tools online that highlight this as an issue.

This here is a trivial case of simply not testing deliverability at all.

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

#175

Post by eli »

tracker1 wrote: post #76
zer00eyz wrote: post #52

Earlier quoted context omitted.

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

I think a mail 2.0 would be notify and pull based.... you notify a recipient's mail server that there's a message from for them, then that server connects to the MX of record for the domain of and retrieves message. Would this make mass emails and spam harder, absolutely. Would it be a huge burden for actual communications with people, not so much. From there actual white/black listing processes would work all that m…

Is the idea that you could decide from the envelope whether you want to even bother fetching the message? Besides that I'm not sure I see the advantage

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

#176

Post by Avamander »

fmbb wrote: post #173
FactolSarin wrote: post #93

Earlier quoted context omitted.

Google is rejecting it to ensure incoming messages aren't spam. SHOULD means "you should do this unless you have a really, really good reason not to." Do they have a good reason not to? It doesn't seem so, meaning Viva is in the wrong here.

Spam senders don’t have pseudorandom number generators?

They're more likely to put in the least amount of effort or care the least about the reasons how the header is used later on.

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

#177

Post by ryandrake »

oasisbob wrote: post #64
basilikum wrote: post #10

With fintech that surprises me not the slightest bit. Financial institutions are filled to the brim with unbelievably incompetent people. A large part of it is probably willful ignorance, too. It's often truly staggering that a financial company I interact with in day to day live is even able to exist. That's until I remember that all the others are just as incompetent. "Major European Payment Processor" really just…

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.

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

#178

Post by jonathanstrange »

ajross wrote: post #128
thayne wrote: post #113

> Who's in the right I don't think either are. The payment processor should be sending it, but, at least according to the RFC, it is incorrect to reject an email that doesn't have it. I suspect the reason it is SHOULD, and not MUST is for backwards compatibility with software that predates the RFC that adds the message-id header. Maybe there is a correlation between missing that header and being spam, but then it sho…

Exactly. This minutiae is all so weird. Email as a formal specification does not work , and the industry as a whole has accepted that for decades now. It's not possible to filter spam from valid traffic without applying a truckload of heuristics and leveraging an ever growing set of auxiliary signals (SPF, DKIM, yada yada). To wit: basically everything in this world is a "SHOULD", at best. The rules are a conversatio…

Then why does my email program reliably distinguish spam from ham without any server-side filtering involved?

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

#179

Post by almosthere »

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

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

The original email RFC is also completely unaware of how bad spam is. Sure it might mention it but it's not really AWARE of the problem. The truth is, companies like Google, Microsoft and a few others have de-facto adjusted the minimum requirements for an email. Signing, anti-spam-agreements, etc.. are the true standard if you want an email to get from point a to b. (none of which are going to be REQUIRED in the RFC)

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

#180

Post by helge9210 »

13415 wrote: post #86
RHSeeger wrote: post #49

Earlier quoted context omitted.

> if you don't use it you should blame only yourself that your messages are not accepted I think it's a gray area - If the receiver declines your message because "Message-id" is required - then I blame the receiver; because that's not true - If the receiver declines your message because "most systems do include it, and it's lack of presence is highly correlated with spam email", then it's on the sender Admittedly, th…

Does it even matter when in reality it's more likely that this is intentional anti-competitive behavior by Google? They once made all emails from my very reputable small German email provider (a company that has existed and provided email services long before Google existed) go into a black whole - not bounce them back or anything like that, mind you, their servers accepted them and made them disappear forever. I was…

Long time ago when I was managing ISP email relay and customers asked "Where is the message I've sent?" seeing in the logs message accepted by receiving SMTP server was the end of the debug for me: I just handed the customer the part of the log and suggested talking to the receiving side IT administrator.
Post reply on HN