Live data from Hacker News

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

atha.io

181–190 of 443 posts

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

#181
post #94

Earlier quoted context omitted.

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…

Not my PM (in the US). My PM would try to avoid anything that is not absolutely necessary and therefore ask developers not to develop anything that isn't a MUST. I know that we like making fun of Europe for their alleged lack of innovation but this isn't a Europe thing.

Implementing a 20 years old needed RFC header is the cutting edge of innovation

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

#182
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.

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]

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

#183
post #163
post #156

Earlier quoted context omitted.

In a completely different field, navigating ships at sea, the Collision Regulations which define how people must conduct ships at sea, they use the words "Shall" and "May" to differentiate legal requirements and what may just be best practice. "Should" intuitively means something more like "May" to me

Happily, the meanings in RFCs are clearly specified, see https://www.rfc-editor.org/rfc/rfc2119 . Note "the full implications must be understood and carefully weighed before choosing a different course". Gmail and the other big hosters have full-time spam teams who spend a lot of time weighing implications, so I assume the implications of this was weighed.

And EVERY rfc has a paragraph talking about rfc 2119 in the preamble.

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

#184
post #150
post #142

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

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

"shall" and "must"

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

#185
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.

I don't think a single spam email has ever crossed into my Fastmail inbox. Granted, every service I sign up for gets it's own masked email. But while the @fastmail.nl email that I chuck on my website gets a fair amount of spam, it always gets categorized correctly.

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

#186
post #158

Earlier quoted context omitted.

> "I don't want to" is not a valid excuse for the client . If you're implementing a server, "the client SHOULD but didn't" isn't a valid excuse to reject a client either. You can do it anyway, you might even have good reasons for it, but then you sure don't get to point at the RFC and call the client broken.

Hearsay has it that the reason is spam. Spam messages are said to have massively higher chances of minor RFC violations when they arrive at the destination server.

Most of the time, in my experience, when one encounters a situation like this in Internet tech (i.e. "why is this suggestion treated like a hard requirement?"), this is the answer: "because attackers found a way to exploit the lack of the suggestion's implementation in the wild, so it is now a hard requirement."

The standards, to my observation, tend to lag the CVEs.

Side-note: If someone has built a reverse-database that annotates RFCs with overriding CVEs that have invalidated or rendered harmful part of the spec, I'd love to put that in my toolbox. It'd be nice-to-have in the extreme if it hasn't been created yet.

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

#187

Huh I've lived in Europe for most of my life and I've never heard of viva except as a poor name choice for Microsoft's corporate Facebook (yammer) Most companies here use stripe on their website.

it's a greek company, if you buy from greek websites i guess you'll deal with it

i'm not greek but a greek ecommerce i buy from uses viva

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

#188
post #142

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

> "I don't want to" is not a valid excuse for the client . If you're implementing a server, "the client SHOULD but didn't" isn't a valid excuse to reject a client either. You can do it anyway, you might even have good reasons for it, but then you sure don't get to point at the RFC and call the client broken.

You are describing MAY.

“MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional… An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)”

Note how it explicitly calls out interoperation with implementations that do or do not implement MAY. As a exception that proves the rule, we can reasonably assume that not interoperating with a system ignoring a SHOULD rule is a correct implementation and it is the fault of whoever is not implementing SHOULD.

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

#189
post #86

Earlier quoted context omitted.

> if you don't use it you should blame only yourself that your messages are not accepted I think it's a gray area - If the receiver declines your message because "Message-id" is required - then I blame the receiver; because that's not true - If the receiver declines your message because "most systems do include it, and it's lack of presence is highly correlated with spam email", then it's on the sender Admittedly, th…

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 to their users because the provider is small. At their scale, "I've forgotten how to count that low" is a real effect. And email, as a protocol, has been pretty busted for decades; it's not Google that made the protocol so open-ended and messy to implement in a way that providers will agree is correct.

> Nothing of significance ever happened when Google had large optics fiber connections with NSA installed illegally and claimed to have no knowledge of it

Nothing of significance outside Google. Inside, Google initiated a technical lift that turned their intranet into an untrusted-by-default ecosystem so that data was encrypted on the fiber (as well as between machines within a datacenter, to head off future compromised-employee attacks). That process took at least five years; I suppose there's a scenario where it was all smoke and mirrors, but being on the inside in the middle of the process, I watched several C-suite who are not particularly good actors be bloody pissed at the US government for putting itself into Google's "threat actor" box and making that much work for the system engineering teams.

Also, an engineer at Google then made an end-to-end email crypto plugin for Chrome, including a flag that was a nod-and-middle-finger to the information revealed in the Snowden documents. https://techcrunch.com/2014/06/04/nsa-mocking-easter-egg-fou...

Post reply on HN