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

131–140 of 443 posts

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

#131

Post by hermannj314 »

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 SHOULD follow the wording of the RFC, you MUST follow Google's interpretation of the RFC.

That is the difference.

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

#132

Post by thatha7777 »

iso1631 wrote: post #8
that_guy_iain wrote: post #3

[flagged]

It does seem unlikely that there are no customers on google workspace who have tried to use viva. I don't do payment processing, and my email is via zoho, so I've no idea how large either of those groups are. I wonder what google workspace support said.

I suspect that Google going out of their way to make this required had a very reasonable and thought-out process, while the sender's omission was on oversight, so I haven't contacted Google Workspace support.

What's truly iffy is that GMail doesn't have the same strict requirements, and there's no way (at least that I found) to turn it off for my Google Workspace domain.

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

#134

Post by mrighele »

The first thing that comes to my mind is: how come viva.com is unable to send emails to google workspaces and nobody at viva.com noticed before ? For how long has this going on ?

The second thing is, what email software are they using ? If it was any relatively used software I would not expect this problem to arise (maybe it is some commond software but misconfigured).

Third, while the header is not mandatory, I usually read SHOULD as a "if you don't implement it prepare for possible problems". SHOULD is not MAY.

Fourth, they should be thankful that Google bounced the messages with some appropriate error explaining how to solve it. I have plenty of issues in the past with both Google and Microsoft where they accept the message for then sending to /dev/null

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

#135

Post by joshuaissac »

hughw wrote: post #91

Postel’s Law would put the onus on Google to be forgiving in what it receives. Unsure how you could safely use a sender-created Message-Id for anything anyway.

Following Postel's law results in the normalisation and proliferation of defective implementations. The actual standard becomes irrelevant, and new implementations have to be coded against the defective ones.

My opinion is that Postel's law should be approached in the same way that Linus Torvalds did CVS when designing Git. If in doubt about an implementation decision, consider what Postel's law would recommend, and then do the exact opposite.

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

#136

Post by psychoslave »

mbreese wrote: post #69
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…

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…

In my experience, email is an unreliable way to communicate any time-bounded critical information. When I want to be sure an email was transmitted on either side, the only reliable way to ensure this is to use a distinct channel to validate reception and confirm content.

That is, when some hotline tell me that they just sent and email with the information, I ensure they hold the line until I got the actual email and checked it delivers the relevant information to fulfill the intended process. And when I want to make sure an email was received, I call the person and ask to check, waiting until confirmation.

It’s not that much SMTP/IMAP per se as the whole ecosystem. People can legitimately get fatigue of "is it in my junk directory", "it might be relayed but only after the overloaded spam/junk analyzer accept it", or whatever can go wrong in the MUA, MSA, MTA, MX, MDA chain. And of course people can simply lie, and pretend the email was sent/received when they couldn’t bother less with the actual delivery status.

There are of course many cases where emails is fantastic.

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

#137

Post by layer8 »

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…

The reason it’s recommended is that it’s useful for detecting when an email you receive is already in your mailbox, so that you don’t accumulate duplicates. Otherwise one would have to compare the complete email, which probably no MUA does. Another reason is that replies can include a reference to the original message, so that it can be properly threaded by MUAs.

So these are mostly quality-of-life reasons, it’s not a reason to reject an email.

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

#138

Post by davoneus »

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.

No, SHOULD is defined in the RFC, not by colloquial usage. Google is on the wrong, regardless of their "safety" intent.

After all, linguistics is full with examples of words that are spelled the same, but have different meaning in different cultures. I'm glad the RFC spelled it out it for everyone.

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

#139

Post by renewiltord »

that_guy_iain wrote: post #3

[flagged]

1. Email didn’t arrive in his inbox of his Google workspace

2. He checked workspace email logs (with admin you can do this on gsuite)

3. It showed the intentional non-accept

4. Comprehending the problem, he switched to personal Gmail

5. The email arrived

6. He informed the sender of the original problem which he worked around

7. Sender is tech-illiterate and did not realize what the problem is. This is common with first line customer support so that happens.

The question to ask is whether you are literate in English or you skimmed too fast. Because I did a 30 s read of the article and got that.

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

#140

Post by lingrush4 »

youknownothing wrote: post #115
s17n wrote: post #94

Earlier quoted context omitted.

The reason that European tech sucks is that people in Europe are open to such arguments. If an engineer in the US started talking about SHOULD vs MUST, some PM would just give them that "what the fuck did I just listen to" face, spend the next few minutes gently trying to convince them that the customer experience matters more than the spec, and if they fail, escalate and get the decision they want. For example, why…

Not my PM (in the US). My PM would try to avoid anything that is not absolutely necessary and therefore ask developers not to develop anything that isn't a MUST. I know that we like making fun of Europe for their alleged lack of innovation but this isn't a Europe thing.

Your PM most definitely would not tell you to skip a feature that is needed for your emails to be delivered to Gmail accounts. What a preposterous thing to lie about.
Post reply on HN