Earlier quoted context omitted.
[flagged]
Dude, you keep on just believing a blog post even though it makes no technical sense. That's why none of the hardcore nerds are even approaching this and why Viva are going to sue. An email bouncing means it was rejected because it did not find an inbox or a recipient. You AI to question if that is true. So if the email service provider says we don't know who that belongs to, why would they provide logs. And what ema…
Major European payment processor can't send email to Google Workspace users
431–440 of 443 posts
Re: Major European payment processor can't send email to Google Workspace users
#432Earlier quoted context omitted.
There is plenty amount of incompetence in FAAMG. Notepad .... Do Europe financial institutions have the same level of corruption as the USA? Such as a credit card company authorizing credit card transactions with incorrect expiration date to maximum profit, Bank of America? Or opening new accounts without consumer consent, Wells Fargo?
> Do Europe financial institutions have the same level of corruption as the USA? lol... how much time do you have? Here's just one to start with off the top of my head: https://en.wikipedia.org/wiki/HSBC#Controversies
Re: Major European payment processor can't send email to Google Workspace users
#433Earlier 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.
Re: Major European payment processor can't send email to Google Workspace users
#434Re: Major European payment processor can't send email to Google Workspace users
#435Earlier quoted context omitted.
text/plain != plaintext This is about media types, not encryption.
Do you think I was talking about encryption, or is it not more likely I meant text/plain given the context?
Re: Major European payment processor can't send email to Google Workspace users
#436Earlier quoted context omitted.
MUST means omission is unacceptable. SHOULD means MUST unless you have a good, well-reasoned excuse.
Incorrect. Not required is not required. You do not need to supply rationale or get agreement by anyone else that your reasons are good in their opinion and not just in your opinion. Should just means the thing is preferred. It's something that is good and useful and helpful to do. That is not "must unless you can convince me that you should be excused".
“ 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.”
Re: Major European payment processor can't send email to Google Workspace users
#437Earlier quoted context omitted.
Incorrect. Not required is not required. You do not need to supply rationale or get agreement by anyone else that your reasons are good in their opinion and not just in your opinion. Should just means the thing is preferred. It's something that is good and useful and helpful to do. That is not "must unless you can convince me that you should be excused".
RFC2119 “ 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.”
Further, not only the presense of the words "should" and the doubling down with "recommended", also the absense of the words "must" or "required" or "shall" is pointed.
Because those words are used elsewhere. When something is actually required, those words are used, and so when they are not used, it is meaningful. It means no one is free to put their own words into the authors mouths and say "well they didn't say it but obviously they pretty much meant required" when they so pointedly chose not to say required.
And it's not a technicality. A thing either is or is not required. There are no other states. The spec does not require it, and so for Google to require it, Google is not adhering to the spec.
Since the spec does not require it, you can't say either that it falls under "full implications". "full implications" cannot include "Some servers might require it", because that would be circular logic. No server can require it in the first place.
Re: Major European payment processor can't send email to Google Workspace users
#438Earlier quoted context omitted.
if you apply that logic every recommendation becomes mandatory no? if the alternative to [not doing a recommended thing] is [failure] then what's the difference between "should" and "must"? "we recommend you leave the keys in the ignition while putting your car in park" "or what?" "or your car may blow up, killing everyone inside. just a recommendation though!"
It makes more sense when you read all of the definitions together https://datatracker.ietf.org/doc/html/rfc2119 : - `MUST: This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.` - `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 implication…
Re: Major European payment processor can't send email to Google Workspace users
#439Email deliverability is the reason I gave up on email entirely for my side project and built on Telegram instead. Setting up SPF, DKIM, DMARC, warming up a domain, monitoring reputation, dealing with bounces and complaints... all of that just to maybe land in someone's inbox. With Telegram you send a message via the Bot API and it arrives. 100% deliverability. No spam filters. No authentication chain. The message jus…
Some of us selfhost email, like me for 30+ years, and have 100% deliverability.
I have had random emails from Google Workspaces to Microsoft 365 be rejected because of a rule that blocked whole IP blocks.
Re: Major European payment processor can't send email to Google Workspace users
#440Email deliverability is the reason I gave up on email entirely for my side project and built on Telegram instead. Setting up SPF, DKIM, DMARC, warming up a domain, monitoring reputation, dealing with bounces and complaints... all of that just to maybe land in someone's inbox. With Telegram you send a message via the Bot API and it arrives. 100% deliverability. No spam filters. No authentication chain. The message jus…