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

251–260 of 443 posts

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

#251

Post by drecked »

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…

That clearly means it’s not required.

How does Google know whether or not the sender has a valid reason? They cannot know that so for them to reject an email for it means they would reject emails that have valid reasons as well.

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

#252

Post by jolmg »

Waterluvian wrote: post #36
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…

What is the point of SHOULD then? (No seriously, I’m asking; are there examples of where it’s actually different from a MUST)? Also this reminds me of something I read somewhere a long time ago: when specifying requirements don’t bother with SHOULD. Either you want it or you don’t. Because if it’s not a requirement, some people won’t implement it. I guess the one time it’s good is if you want an optional feature or a…

I SHOULD have 8 hours of sleep every night. It's RECOMMENDED. However, there are times where it's best I don't (e.g. because of work, or travel, or needing to take someone to the hospital, etc.). It's definitely not that I MUST sleep 8 hours every night.

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

#253

Post by eduction »

I’m sorry but in the context of a 50 year old technology like email, 2008 was yesterday. Gmail is in the wrong, you don’t get to just update the standard for email like it’s TikTok content or a Roblox update or whatever.

Email was here long before Gmail and will be here long after Google abandons it.

This is why I don’t use Gmail.

Also, get off my lawn.

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

#254

Post by Dylan16807 »

johnnyfaehell wrote: post #161
that_guy_iain wrote: post #3

[flagged]

[flagged]

EU doesn't require edits, what the hell?

And nobody "decided to stop you" if you just hit the end of the 2 hour edit window.

But go on, what's your tagline.

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

#255

Post by buran77 »

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 server has considered fully the implications

The server "considers" nothing. The considerations are for the human implementers to make when building their software. And they can never presume to know why the software on the other side is working a certain way. Only that the RFC didn't make something mandatory.

The rejection isn't to be compliant with the RFC, it's a choice made by the server implementers.

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

#257

Post by hsbauauvhabzb »

behringer wrote: post #241
hsbauauvhabzb wrote: post #217

Earlier quoted context omitted.

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.

Is the server somehow unable to inject an ID if the sender did not send one? Stop hiding behind policy and think for yourself.

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

#258

Post by golem14 »

Hilarious - German users lecturing Google on how to interpret the English RFC?

I say this lovingly, having significant German ancestry:)

But taking a step back :

did viva previously send message ids and pushed a change to prod to strip it? Was it on purpose or an accident?

And other email providers like proton or Hotmail - do they accept messages without message ids?

Have other clients of Google workspace complained about this issue?

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

#259

Post by geocar »

hsbauauvhabzb wrote: post #220
geocar wrote: post #210

Earlier quoted context omitted.

> How is not having a message-id a security risk? CVE classify a lot of things that have nothing to do with security. Not having a Message-ID can cause problems for loop-detection (especially on busy netnews and mailing lists), and with reliable delivery status notification. Dealing with these things for clients who can't read the RFC wastes memory and time which can potentially deny legitimate users access to servic…

So add a message id at the first stop, or hard ban the sender server version until they confirm. A midway point that involves a doom switch is not a good option.

> So add a message id at the first stop

That should have already happened. Google is not the "first stop".

> hard ban the sender server version until they confirm

SMTP clients do not announce their version.

Also I don't work for you, stop telling me what to do.

> A midway point that involves a doom switch is not a good option.

No shit. That's almost certainly a big part of why Google blocks messages from being transited without a Message-ID.

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

#260

Post by leni536 »

jasode wrote: post #168
stefan_ wrote: post #152

Earlier quoted context omitted.

Why? If I'm writing a mail receiver, and I'm told there is some unique ID generated by the sender in a loosely specified way , the first thing I'm doing is ignoring that value forever . One lesson surely most everyone learns in CS is that unique identifiers are maybe unique to the system generating them , but to rely on foreign generated IDs being unique globally is a terrible idea that will break within the minute.…

>Why? If I'm writing a mail receiver, and I'm told there is some unique ID generated by the sender in a loosely specified way, the first thing I'm doing is ignoring that value forever. [...] So at that point the ID has no value to me Your framework of analysis is based on someone else's database key ids being irrelevant to you. That's true. But another framework of analysis is tracking statistical correlations of wha…

Ah, so it's just the evil bit, or lack of.
Post reply on HN