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

221–230 of 443 posts

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

#221

Post by ZoneZealot »

realusername wrote: post #211
fweimer wrote: post #209

The Gmail requirement is actually slightly different: the header must be present and unique. Gmail only keeps one copy of a message per user and message ID. Combined with a mail source that uses predictable message IDs (such as Github), you can abuse this to suppress delivery of certain messages to Gmail users.

Interesting, but what do you gain to send an email which you know will not land?

They mean to send an email in advance, with a message ID that would later be used in the target email. First email gets ignored, moved to spam, or not read yet. Then the target email gets sent with the predicable message ID, and gets bounced.

Comments on issues use the format

A mitigation to this would be to take the combination of message ID and the sending domain and use that as the unique value, because message ID is not guaranteed to actually contain a domain label that's owned by the sender.

For example SendGrid's message IDs are .

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

#222

Post by tracker1 »

eli wrote: post #175
tracker1 wrote: post #76

Earlier quoted context omitted.

I think a mail 2.0 would be notify and pull based.... you notify a recipient's mail server that there's a message from for them, then that server connects to the MX of record for the domain of and retrieves message. Would this make mass emails and spam harder, absolutely. Would it be a huge burden for actual communications with people, not so much. From there actual white/black listing processes would work all that m…

Is the idea that you could decide from the envelope whether you want to even bother fetching the message? Besides that I'm not sure I see the advantage

You have to have a working mail server attached to a domain to be able to send mail... that's the big part. Right now, email can more or less come to anywhere from anywhere as anyone. There are extensions for signing connections, tls, etc... but in general SMTP at it's core is pretty open and there have been efforts to close this.

It would simply close the loop and push the burden of the messages onto the sender's system mostly.

And yes, you can decide from the envelope, and a higher chance of envelope validity.

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

#223

Post by throw7 »

alistairSH wrote: post #159
ragall wrote: post #143

Earlier quoted context omitted.

The RFC says a SHOULD is to be treated like a MUST, but well-justified exceptions are allowed.

Per RFC2119: 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. So, it's fairly explicit that the sender should use message-id unless there's a good reason to not do so. The spec is quiet about the recipients behavior…

Not a specification but "Be liberal in what you accept?" comes to mind. (which I always personally hated but i'm just one shoveler).

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

#224

Post by fweimer »

ZoneZealot wrote: post #221
realusername wrote: post #211

Earlier quoted context omitted.

Interesting, but what do you gain to send an email which you know will not land?

They mean to send an email in advance, with a message ID that would later be used in the target email. First email gets ignored, moved to spam, or not read yet. Then the target email gets sent with the predicable message ID, and gets bounced. Comments on issues use the format A mitigation to this would be to take the combination of message ID and the sending domain and use that as the unique value, because message ID…

Minor correction: The message doesn't get bounced, it gets de-duplicated against the first message. Effectively, it's deleted.

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

#226

Post by ajross »

jonathanstrange wrote: post #178
ajross wrote: post #128

Earlier quoted context omitted.

Exactly. This minutiae is all so weird. Email as a formal specification does not work , and the industry as a whole has accepted that for decades now. It's not possible to filter spam from valid traffic without applying a truckload of heuristics and leveraging an ever growing set of auxiliary signals (SPF, DKIM, yada yada). To wit: basically everything in this world is a "SHOULD", at best. The rules are a conversatio…

Then why does my email program reliably distinguish spam from ham without any server-side filtering involved?

If you have a client app that you think is reliably filtering spam, then to be blunt: you aren't receiving any spam, at least to first approximation. My stack of stuff on my three decade old personal account has a 95%+ hit rate (something I might naively be tempted to label as "reliably filtering spam"), and I see see more spam than signal in the inbox.

GMail, on the other hand, is damn close to 100%. And it does it through excruciating application of heuristics like "don't trust agents that don't set SHOULD headers".

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

#227

Post by patrickmcnamara »

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…

Do bugs and bad implementations not exist in US software? If an US company did this, nobody would be bloviating about how it is a cultural issue or whatever.

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

#228

Post by kuschku »

dwedge wrote: post #213
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?

I had one who sent me the booking details of another client in the plaintext part. I reported it to them nearly a year ago and they didn't reply, so screw anonymity, it was Avis.

If you're in EU or California, you should probably email the local data privacy official's offices about that.

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

#229

Post by thatha7777 »

gethly wrote: post #103

Google NOT following the spec is not surprising. SHOULD does not mean MUST and they are completely in the wrong here.

The definition of SHOULD is "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."

I suspect viva.com didn't consider the full implications, and I suspect Google did some hard math on hours saved for their customers

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

#230

Post by someonebaggy »

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…

[dead]
Post reply on HN