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

351–360 of 443 posts

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

#351

Post by direwolf20 »

dathinab wrote: post #316
afavour wrote: post #42

I have some level of sympathy with Google here, which isn’t something I often say. I recently switched from Gmail to Fastmail and by and large I’m happy with it. But I’ve been surprised by the amount of spam and (particularly) phishing emails I get in a regular basis. Google might be too strict in its filtering but it does serve a legitimate purpose.

> Google might be too strict in its filtering they are, but not in this case Message-Id being basically required for _automated_ mails (very similar mail send to a lot of people) requiring Message-Id is a de-facto industry standard. Sure some providers don't care and some might make it just more likely that your mail ends up in spam. But this could have happened with pretty much any mail provider widely used by compa…

In Europe you can sue Microsoft for not accepting your emails that aren't spam.

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

#352

Post by nosianu »

shakna wrote: post #299
zdragnar wrote: post #295

Earlier quoted context omitted.

[flagged]

No, its not a "required"... It means someone may have reasons not to use something, and so spec implementors need to allow for circumstances where it is not present. Those reasons can be anything. Legal, practical, technological, ideaological. You don't know. All you know is not using it is explicitly permitted.

"permitted" is a pretty empty word in the given context. Because dropping such emails is equally "permitted". Sure, there will be no arrests made, but there will be consequences. And those are what this article is about.

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

#353

Post by Aldipower »

Arnt wrote: post #142
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…

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

It isn't a requirement. SHOULD is conditional. MUST is _not_ conditional.

Sure, you can argue, if you require that the email reach their destination, it is required to set this. ;-)

But I am totally with the OP here. SHOULD was never a requirement, just a recommendation that is maybe better to follow.

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

#355

Post by shakna »

nosianu wrote: post #352
shakna wrote: post #299

Earlier quoted context omitted.

No, its not a "required"... It means someone may have reasons not to use something, and so spec implementors need to allow for circumstances where it is not present. Those reasons can be anything. Legal, practical, technological, ideaological. You don't know. All you know is not using it is explicitly permitted.

"permitted" is a pretty empty word in the given context. Because dropping such emails is equally "permitted". Sure, there will be no arrests made, but there will be consequences. And those are what this article is about.

If that's your line, then I am equally permitted to send random binary blobs along the way. Not a crime, so totally permitted. They'll just drop the connection.

Buuut I don't think that is at all relevant to the discussion at hand.

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

#356

Post by mrweasel »

s17n wrote: post #94
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 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…

Standards are important, and the meaning assigned to words are important, but if your very important email does go through, because Google thinks you're wrong, you add the bloody message-id. I really do agree, I don't care about the linguistic/legal/standard/technological reason as to why Google might be wrong, if I can't deliver email to Gsuite customers, I add the message-id.

You're precisely right that customer experience matter, but I wouldn't put it past some conservative European company to go: Well Google is wrong, so they should fix that. Google doesn't care, you can't make them care, you can't even contact them. Just make it work for your customer.

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

#357

Post by mrweasel »

saurik wrote: 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?

This might be me being old, but I still don't understand why html emails aren't the exception. If you want to do a fancy newsletter, trying to sell me crap, I can see why you'd need the images, the css and html. In most other cases, I don't really get the point.

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

#359

Post by mort96 »

azernik wrote: post #350
BeetleB wrote: post #301

Earlier quoted context omitted.

Nope, it's exactly what it says: RECOMMENDED. Any time any document (standards or otherwise) says something is recommended, then of course you should think it through before going against the recommendation. Going from their verbiage to: > SHOULD is effectively REQUIRED unless it conflicts with another standards requirement or you have a very specific edge case. is a fairly big leap.

"The full implications must be understood and carefully weighed before choosing a different course." (emphasis mine) i.e. you are required to have a good reason not to do it.

Can you start actually reading what you quote? "The implications must be understood and weighed" does not mean "you are required to have a good reason not to do it". I can know of the Message-ID field, understand what it's used for, and carefully weigh the possible lack of interoperability against the effort required, concluding that I'm too lazy to do it right now. I have then understood and carefully weighed the implications before choosing a different course, but I don't have a good reason to.

Words mean things, especially in standard texts. You can't just carelessly rewrite sentences using not-quite-synonyms like you're doing here.

Oh, and that "must" is not a "MUST". Had the text said "The full implications MUST be understood ..." it would have been a proper requirement by the standard, but this lower-case "must" is just normal part of prose and not the magical "MUST" word which formally imposes a requirement.

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

#360

Post by mort96 »

sigseg1v wrote: post #348
HDThoreaun wrote: post #327

Earlier quoted context omitted.

This very clearly says that SHOULD is not effectively REQUIRED at all, and is fact nothing more than RECOMMENDED. Really not sure how you misinterpreted this so badly

It's not required but they need to understand the implications. In this case the implication is that Google drops the mail. So clearly they didn't understand the implications.

So you agree that calling it a requirement is wrong?
Post reply on HN