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

371–380 of 443 posts

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

#371

Post by whizzter »

fosron wrote: 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.

Since workspaces are probably tied to custom domains all they see if only cursorly looking are "random" businesses with bounces (as TFA mentions, Gmail addresses seem to work fine), sure if you look closer you'll notice the MX might be a google one but going from the cursory look to a closer one takes a bit of time.

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

#372

Post by cientifico »

This feels jumping on the train of complain about Europe and fully bias.

If I apply my own bias I will call it:

    American companies abuse their dominance my enforcing non documented requirements, making other companies not able to reach their users.

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

#373

Post by Dylan16807 »

geocar wrote: post #369
Dylan16807 wrote: post #294

Earlier quoted context omitted.

You are confused about what I'm doing. I'm not telling anyone what to do. I'm saying what category their actions fall into. And the line of yours I quoted is still not supported by anything.

> You are confused about what I'm doing. Absolutely. And if you're not confused by what I said, that's not obvious in the slightest. > I'm not telling anyone what to do. So you say. > I'm saying what category their actions fall into. I think that's pretty weird that you think you get to decide that all by yourself. But I'm not playing, because you're right: I don't know why you would be doing that. > And the line of…

> But I'm not playing, because you're right: I don't know why you would be doing that.

This is the comment you originally replied to:

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

They're talking about how to categorize actions, just like I am.

So I thought you were playing on that same topic.

But if you weren't on that topic, and given that you quoted only the first one of those sentences, I have a guess.

I think you didn't realize how the second sentence affects the meaning of the first one, and you misunderstood what they were saying as trying to tell servers they can't reject. They were not trying to tell servers they can't reject.

If that's the case, then this whole line of conversation is pointless, because you were rebutting an argument that nobody made.

> It's a description of the behaviour of other Internet hosts, and it's a description of exactly what is happening in the linked article.

Taking a description of behavior and throwing an RFC-style "SHOULD" in front is only going to be correct if you get lucky. "is" and "SHOULD" are different things!

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

#374

Post by Dylan16807 »

strken wrote: post #303
Alive-in-2025 wrote: post #284

Earlier quoted context omitted.

Thank you for that. So should is optional, people!

Pulling exact quotes out, SHOULD means "there may exist valid reasons in particular circumstances to ignore a particular item" while MAY means "an item is truly optional." I don't think this can be interpreted as simply "should is optional".

They're both optional, but one comes attached to a big warning message.

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

#375

Post by Dylan16807 »

ragall wrote: post #144
davoneus wrote: post #138

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.

RFC speak requires you to think for a while about skipping a SHOULD. It doesn't require strong justification.

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

#376

Post by RobertoG »

tempestn wrote: post #341

I've often found when receiving a clueless support response like this, it can be effective to just follow up with a polite request to forward the ticket to an engineer or developer. Usually the front-line csr simply hasn't understood the issue. In this case I would say something like, "Yes, I managed to work around the issue by switching to my personal email address, but this bug is still preventing me from using my…

But imagine that you do that, and they solve the problem. What would you write in your blog about?

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

#377

Post by Dylan16807 »

lingrush4 wrote: post #140
youknownothing wrote: post #115

Earlier quoted context omitted.

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.

Your PM most definitely would not tell you to skip a feature that is needed for your emails to be delivered to Gmail accounts. What a preposterous thing to lie about.

The PM wouldn't know about that gmail behavior at that point in the development cycle.

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

#378

Post by DavidPiper »

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.

Just to add another data point - I recently switched as well and have seen no uptick in spam at all. Could just be my emailing habits though? Not sure.

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

#379

Post by citrin_ru »

pilif wrote: post #35
citrin_ru wrote: post #28

Earlier quoted context omitted.

You can argue that you not obligated to use message-id but if you don't use it you should blame only yourself that your messages are not accepted. In requiring message-id I would side with google (though in general I think they anti-spam is too aggressive and lacks ways to report false positives). Full RFC compliance (as in not only MUST but also SHOULD unless you have a very good reason) is the easiest part of makin…

On the other hand, by erroneously treating a SHOULD as a MUST, I would say that Google is the one who's not RFC-compliant

RFC cannot force a mail server to accept spam. You may argue that requiring message-id is a bad anti-spam policy but it does reduce amount of spam. In my observations around a half or messages without message-id are spam. I would not use personally this as the only reason to reject a message but I understand why someone may choose to do.

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

#380

Post by cmsefton »

BeetleB wrote: post #244
Arnt wrote: 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/…

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

Agreed. We use RFC language at work for documents, and whenever I see someone using the word SHOULD, I always ask what is the MAY where you don't need to do the thing? If they can't think of one, then make it a MUST. SHOULD always means there are valid reasons to not do it.
Post reply on HN