Live data from Hacker News

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

atha.io

141–150 of 443 posts

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

#141
post #101
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 assume that internet standards are prescriptivist; that the document describes how it is to be implemented. In practice it's often descriptivist, with the standards documents playing catch-up with how things are actually going in practice. Anyway, in general you can expect that doing unusual but technically valid things with email headers will very often get your messages rejected or filtered as spam.

Standards are definitely prescriptive. But just like a medical prescription, it doesn’t ensure that actors in the wild will conform to what’s prescribed. People will not follow prescriptions for whatever reason, willingly or otherwise. It doesn’t mean the document wasn’t prescriptive.

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

#142

> 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/rfc/rfc6409.html#section-8.3 The SHOULD lets those messages be valid. Low-entropy devices that can't generate a good random ID are rare these days, but old devices remain in service, so the workaround is IMO justified.

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

#143
post #35

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…

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

The RFC says a SHOULD is to be treated like a MUST, but well-justified exceptions are allowed.

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

#144

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.

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.

The RFC says a SHOULD is to be treated like a MUST, but well-justified exceptions are allowed.

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

#145
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?

the best is when some put the same payload in the text/plain part as in the text/html part. yes. the html source. as text/plain.

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

#146
post #61

Worked on an ESP. We had a couple of server software we used on low-level for sending. None of them would accept the message without a Message-ID. But even if you have a super-custom, SMTP-injecting service built, how can you ignore all of these bounces from a provider thats likeliest to be the major one you are sending to? Unthinkable. I would not like to have business with such a payment provider.

I doubt Google Workspace is going to be the major provider for European businesses

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

#147
post #8

Earlier quoted context omitted.

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.

Wikipedia says Viva.com is a multi-billion dollar startup

It seems unlikely you're the first company using viva.com and using google workspace.

Clearly the problem here is that viva.com emails aren't arriving on your google workspace, despite what their support process says.

viva.com emails do arrive on other email providers, so seems unlikely to be problem with your viva.com account

It seems unlikely workplace blocks all viva.com emails otherwise more than you would have complained.

Whether that's viva's problem or google's problem is a separate problem.

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

#149

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

My take, as a postmaster for hosting company, who don't have any sympathy to gmail (that should be visible from my comments history): Message-ID is absolutely MUST in production e-mails. You can send your test stuff without it, but real messages always have it. Not having Message-ID's causes lot of fun things. All somewhat competent software is capable to add Message-ID's, so lack of it is good indication of poorly made custom (usually spamming) solution.

Rspamd and spamassassin have missing MID check in their default rules, I am sure that most antispam software is same.

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

#150
post #142

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

As someone who does systems engineering, the only valid requirements include the word "shall".
Post reply on HN