The most damning thing about this is they didn't test their email infra w/ Google Workspaces. Imagine what else they didn't test.
Major European payment processor can't send email to Google Workspace users
271–280 of 443 posts
Re: Major European payment processor can't send email to Google Workspace users
#272Re: Major European payment processor can't send email to Google Workspace users
#273Re: Major European payment processor can't send email to Google Workspace users
#274Earlier quoted context omitted.
If it was unimportant it would be MAY.
Is the server somehow unable to inject an ID if the sender did not send one? Stop hiding behind policy and think for yourself.
Yes. https://www.rfc-editor.org/rfc/rfc2821#section-6.3 refers to servers that do this and says very clearly:
These changes MUST NOT be applied by an SMTP server that
provides an intermediate relay function.
That's Google in this situation.> Stop hiding behind policy and think for yourself.
Sometimes you should think for yourself, but sometimes, and friend let me tell you this is one of those times, you should take some time to read all of the things that other people have thought about a subject, especially when that subject is as big and old as email.
There is no good reason viva couldn't make a Message-ID, but there's a good reason to believe they can't handle delivery status notifications, and if they can't do that, they are causing bigger problems than just this.
Re: Major European payment processor can't send email to Google Workspace users
#275> 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…
- In most cases, you are expected to follow it.
- You can choose not to follow it, but you must have a very good reason.
For example, RFC 7231 say that there should be DATE header but some embedded devices have no real-time clock so it ok not to implement.
Re: Major European payment processor can't send email to Google Workspace users
#276Earlier quoted context omitted.
> SHOULD is a requirement. I once had a job where reading standards documents was my bread and butter. SHOULD is not a requirement. It is a recommendation. For requirements they use SHALL. My team was writing code that was safety related. Bad bugs could mean lives lost. We happily ignored a lot of SHOULDs and were open about it. We did it not because we had a good reason, but because it was convenient. We never justi…
Yes, except there seems to be a move on the best words from SHALL to MUST and from SHOULD to MAY. IANAL but I recall reading this in e.g. legal language guidance sites.
Re: Major European payment processor can't send email to Google Workspace users
#277Earlier quoted context omitted.
...and you'd be wrong.
For now, but with EU digital sovereignty efforts in full swing, it's possible this changes over time. More so if the EU uses regulation to dissuade the use of US Big Tech products and services.
Re: Major European payment processor can't send email to Google Workspace users
#278> 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/…
Re: Major European payment processor can't send email to Google Workspace users
#279Re: Major European payment processor can't send email to Google Workspace users
#280Earlier quoted context omitted.
This is the one that gets me - sometimes you're forced to work with systems that do annoying things that you have to accommodate. It's annoying, but it's more important to do the thing that prevents your users from having issues than it is to be theoretically right about whether something's required by a standard. I've dealt with many worse cases than this, where the systems I was integrating with were doing things t…
[dead]
To unblock myself, I switched to a personal @gmail.com address for the account. Gmail's own receiving infrastructure is apparently more lenient with messages, or perhaps routes them differently. The verification email came through.
So it's only an issue for people paying for Google's hosted email—a much smaller set!