321–330 of 443 posts
Earlier quoted context omitted.
While there is some truth in while you saying, I have to say that from my European perspective all the big American companies feel enormously bloated. For example, I've recently learned thats Atlassian has 13000 employees, and I have to ask myself, what do all those people do?
I bet Atlassian's email notifications never bounced.
https://www.bleepingcomputer.com/news/security/atlassian-con...
It is a requirement for being able to reply to messages and in general for email threading.
Message-ID is a requirement to archive email.
Practically every email client has included Message-ID since dial-up internet was fast and fashionable.
Given all of the above I am amazed more places don't drop email without a Message-ID.
Not including a Message-ID seems to be saying you don't want replies and you don't want your message to be archived. That seems very shady to me.
Earlier quoted context omitted.
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)
Earlier quoted context omitted.
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…
At scale, it's very hard to distinguish malicious intent from the simple consequence of being the largest operator in a space so any motion one makes makes waves. For what it's worth: having seen some of how the sausage is made, Google isn't particularly interested in screwing over a small reputable German provider. But they also aren't particularly interested in supporting such a provider's desire to route messages…
> This experience fits a pattern I keep running into with European business-facing APIs and services. Something is always a little bit broken. I feel like this isn't just business services though. American engineers are used to working for either big tech or "Silicon Valley inc." European engineers are used to working for Volkswagen, Ikea or Ryanair. Very different kinds of businesses who treat tech very differently.…
I'm an European engineer and I can confirm that our tech is often broken and customer-reachable people are usually obtuse and hostile about it. We don't even seem to properly implement our own legal requirements. Sometimes, Americans implement the RGPD better than we do.
edit: It seems Viva primarily is a neobank, not a payment processor. I'd never even heard of it until today. It's tiny compared to Revolut, Monzo etc. And tiny compared to an actual payment processor eg Worldline (French, 18,000 employees)
Earlier 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…
Maybe the standards documents you are used to differ from RFCs, but here is the official language: 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. SHOULD is effectively REQUIRED unless it conflicts with another stan…
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
That clearly means it’s not required. How does Google know whether or not the sender has a valid reason? They cannot know that so for them to reject an email for it means they would reject emails that have valid reasons as well.
How would the sender know the consequences of sending without the header? You shouldn’t assume anything here. As a sender, you should include it unless you’ve already worked out what the recipient is expecting or how it will be handled. Doing this with email is silly because the client is sennding to so many different servers they know nothing about so it’s basically a requirement to include it.