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

241–250 of 443 posts

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

#241

Post by behringer »

hsbauauvhabzb wrote: post #217
geocar wrote: post #203

Earlier quoted context omitted.

> isn't a valid excuse to reject a client either. Yes it absolutely is: https://www.rfc-editor.org/rfc/rfc2119 is quite clear. 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. If the client SHOULD do something and do…

Either the server must explicitly confirm to servers or the clients must accept everything. Otherwise message delivery is not guaranteed. In the context of an email protocol, this often is a silent failure which causes real-world problems. I don’t care what the protocol rfc says, the client arbitrarily rejecting an email from the server for some missing unimportant header (for deduction detection?) is silly.

If it was unimportant it would be MAY.

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

#242

Post by pamcake »

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.

When producing a message, it SHOULD have the id. With or withot it is compliant.

On the other end, we may receive messages with or without. Both are valid. We MUST therefore accept both variations.

The second one is a consequence of the former. So yes Google is the violating party.

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

#243

Post by torlavd »

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…

Standard RFC naming, optional field.

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

#244

Post by BeetleB »

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

> 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 justified it. Before our code could be released, everything was audited by a 3rd party auditor.

It's totally fine to ignore SHOULD.

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

#245

Post by Dylan16807 »

geocar wrote: post #203
st_goliath wrote: post #151

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.

> isn't a valid excuse to reject a client either. Yes it absolutely is: https://www.rfc-editor.org/rfc/rfc2119 is quite clear. 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. If the client SHOULD do something and do…

> If the client SHOULD do something and doesn't, and your server does not know why, you SHOULD disconnect and move on.

That is not a rule.

In this situation the server can reject any message if it wants to, and not doing a SHOULD tests the server's patience, but it's still ultimately in the "server wanted to" category, not the "RFC was violated" category.

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

#246

Post by SecretDreams »

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

Should = internal target

Must = external requirement

I cannot fathom how you think should* would act as a requirement in any sense of the world.

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

#247

Post by jiggawatts »

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 HTTP User-Agent header is also optional, but if you omit it, something like half of all endpoints will respond with a 500 error code.

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

#248

Post by atmosx »

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.

> I would not like to have business with such a payment provider.

Chances are that the decision-makers in most companies don't care about the technicalities (i.e. which email you used for registration) - they want to get up and running.

The reason that Viva doesn't care, I assume, is the reason Google workspace doesn't care: they're both too big to care for 5% of their clients won't do the extra work. They know that their, usually much smaller clients, will "figure it out" by i.e. using another setup that works™. So why bother?

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

#249

Post by atmosx »

idopmstuff wrote: post #74
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.

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…

> Maybe Google's wrong here, but how do you not just implement the solution anyway?

But they just did (make it work). The logical assumption is that most ppl did the same, just used another email provider. Why would viva care? (same as google, why would google care?).

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

#250

Post by shadowgovt »

atherton94027 wrote: post #192
shadowgovt wrote: post #186

Earlier quoted context omitted.

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…

How is not having a message-id a security risk? It seems that Gmail is being pedantic for no reason

Because in practice it showed up for a period of time as a common thing in spam-senders. They were trying to maximize throughput and minimize software maintenance costs, so they leave out things that the spec says are optional. But that makes "a commonly-implemented optional thing was left out" into a stronger spam signal.

Is it still a strong spam signal? Hard to say. Sources disagree. But as with laws, heuristics, once added, are often sticky.

Post reply on HN