Live data from Hacker News

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

atha.io

41–50 of 443 posts

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

#41
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 emails out of our servers just fine!"

Nobody understands that deliverability has gotten immensely harder these days, and trying to DIY it if its not your core business is just plain stupid. I would never in a million years try to roll my own email, it's nightmarish legacy cruft and footguns all the way down, in everything from IP/Domain Rep to something as simple as the HTML in the email templates themselves.

Microsoft Outlook and Gmail have the last word on everything in email, and their defacto duopoly (over B2B and consumer email respectively) means you play by the rules they set in 2008 and are too lazy to change or you don't get delivered. The protocol of email exists separately from the world of the actual inbox providers, which are locked down to insane degree given the security/spam concerns with email.

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

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

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

#43

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…

SHOULD generally means: some people might require it. implement it for best results

backward compatibility makes it hard to add MUST. using SHOULD is a good alternative

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

#44
post #21

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.

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

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

#45

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.

[flagged]

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

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

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

#47
> For viva.com's engineering team, in case this reaches you: add a Message-ID header to your outgoing transactional emails.

Don't know what they're using for sending emails, but that's something that should be handled by their email service provider, unless they're hosting their own email servers.

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

#48

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

I would read this as a requirement for email to be 'legit' and not classified as spam.

Sure, you can send email with whatever headers you want, use weird combos, IP addresses, reply-to, and it might be still a technically valid email, but not something that should land in people's inboxes.

Also, a payment processor not testing their email on the most popular email provider in the world is quite ridiculous.

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

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

> 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, the end result is the same.

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

#50

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…

“When jump getting over a wall, you SHOULD use three points of contact.”

For most cases you should use three points of contact. However, there may be other situations for example if someone is giving you a leg up, or you can pole vault, where another solution is preferred.

Post reply on HN