Live data from Hacker News

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

atha.io

331–340 of 443 posts

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

#331
I went through this hell last year when trying to tell my customers I had to change payment processors.

In my case it turns out I was victim of Google having a beef with afraid.org years ago (the DNS authoritative record for my domain). 100% of my emails to gmail were going to spam, as soon as I switched NS record to fastmail (with same zone file) I hit the inbox.

I never would have caught it without using this site: https://www.gmass.co/inbox

I did not show up on any of the major blacklists with mxtoolbox, this took months to figure out and I felt like I was going insane with hardly anyone responding to my emails.

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

#332

Typically I'm a DIY type who loves tinkering and building... HOWEVER, I have learned the hard way to never apply that spirit to email. In Europe you see this stuff all the time with old school "IT" (what old industrial companies call tech) people balking at the prices of commercial API-based senders and email marketing ESPs. "Money to send emails in the cloud? HAH! Back at Siemens in 90s we were running millions of e…

I recently had the misfortune of looking into email delivery to help a small business. I came out tired.

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

#333

With fintech that surprises me not the slightest bit. Financial institutions are filled to the brim with unbelievably incompetent people. A large part of it is probably willful ignorance, too. It's often truly staggering that a financial company I interact with in day to day live is even able to exist. That's until I remember that all the others are just as incompetent. "Major European Payment Processor" really just…

[deleted]

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

#334
post #94

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

Seriously, I hope that none of the posters upthread arguing about SHOULD v/s MUST in some standards body document are in charge of real world money making software.

Google and Microsoft's email practices define a pseudo-RFC in practice. As an engineer, I hate this. As a civic participant I can vote against it. But as a person that sells my software services for a living, I am going to implement the Google/Microsoft standards to the letter, not argue about definitions in an RFC.

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

#335
post #84
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 find the ones that try to be cute the most frustrating because these appear on the new message notifications so I can't just delete them straight from the notification. We'd love to share this exciting announcement but you'll a different email app. Although I guess the argument will be that email clients should use AI to summarise the HTML into a plain text summary.

> Although I guess the argument will be that email clients should use AI to summarise the HTML into a plain text summary.

Or you could pass it through ~5,000 lines of C [1] and you will have it done in milliseconds even on hardware that would be old enough to drink.

[1]: https://codemadness.org/webdump.html

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

#336
post #210

Earlier quoted context omitted.

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

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

Well, gmail does not manage usenet groups and mailing lists. Delivery status notifications are considered best effort so it wouldn't make sense to block messages for that case.

Additionally, Gmail adds its own message identifier on every message (g-msgid) because it knows that message ids can not be trusted to be unique.

Finally just calling me ignorant is the cherry on top – please try to keep things civil on here.

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

#337

Earlier quoted context omitted.

The biggest disappointment in my 30 years of adulting has been how much absolute, shameless incompetence is out there in the workforce. When I was a kid, I naively thought that adults were smart and knew what they are doing. Then I got into industry and saw so many people just outright bluffing for 8 hours a day before going home, day in and day out. It's amazing that society even functions at all.

I think that's actually an interesting feature of society as a macro system. It is very fault tolerant, which is frustrating for any power user but without which the system as a whole would not function at all.

Or without which the system would function much better because all poorly functioning systems would fail, forcing designers to focus on fixing the faults

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

#338

Earlier quoted context omitted.

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

Email is about standards like browsers were about standards in 2017...

Browsers are still heavily standardized. Processes and organizations have evolved, but they still develop plenty of specifications and standards.

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

#339
post #35

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

Did i miss the part of the RFC that says google must accept every message? Pretty sure the RFC allows email providers to reject any message they feel like.

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

#340
post #252

Earlier quoted context omitted.

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.

Yeah, and sometimes if you pull an all nighter bad things happen as a result of lack of sleep. So it is an apt metaphor.
Post reply on HN