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.
Major European payment processor can't send email to Google Workspace users
61–70 of 443 posts
Re: Major European payment processor can't send email to Google Workspace users
#62> For viva.com's engineering team, in case this reaches you: add a Message-ID header to your outgoing transactional emails. Don't know what they're using for sending emails, but that's something that should be handled by their email service provider, unless they're hosting their own email servers.
Interestingly the MX record of via.com points to Google, but their verification emails could come from anywhere of course. The IP address in the log is also a Google IP, although that could also be the receiving IP.
Re: Major European payment processor can't send email to Google Workspace users
#63Maybe that's something to report to the "European System of Financial Supervision" or some other EU government agency.
They even have a Whistleblowing link at the bottom of their website: https://www.bankingsupervision.europa.eu/about/esfs/html/ind...
Re: Major European payment processor can't send email to Google Workspace users
#64With 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…
With a broad statement like this, I would usually just suggest this is inflammatory and surely overstated.
However, I've also worked at a financial institution which used core systems by Harland Financial Systems. Their "encryption" for data in transit from teller workstations to the core system was just a two byte XOR, and they sent the key at the beginning of the connection!
Was so unbelievable to be able to crack this in under a half-hour after noticing patterns in a PCAP. Wouldn't have believed it if I hadn't seen it with my own eyes.
That fraud was good enough for our regulators and theirs, so I have no doubt the industry is filled with rotten incompetence through and through.
Re: Major European payment processor can't send email to Google Workspace users
#65I 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.
I've considered this switch. You're saying that previously gmail was dropping the emails, or they were landing in spam?
Re: Major European payment processor can't send email to Google Workspace users
#66> Why this matters
Hello AI (Claude?)
Re: Major European payment processor can't send email to Google Workspace users
#67If that's how they handle email, I wouldn't want to see what they do with payment data.
Re: Major European payment processor can't send email to Google Workspace users
#68Earlier quoted context omitted.
It always amazes me how people can read a blog post like this one that has a clear description of the problem with a log excerpts demonstrating the problem, and then people will confidently make up a completely different scenario that was not mentioned at all and blame the problem on that.
[flagged]
Please read the blog post you are making such strong claims about.
Re: Major European payment processor can't send email to Google Workspace users
#69Earlier 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…
> if you don't use it you should blame only yourself that your messages are not accepted I think it's a gray area - If the receiver declines your message because "Message-id" is required - then I blame the receiver; because that's not true - If the receiver declines your message because "most systems do include it, and it's lack of presence is highly correlated with spam email", then it's on the sender Admittedly, th…
I think it's the latter. But, in either case, you're right in that you get the same result.
Now, let's assume that if it is the latter (it's spam related), and Google were to accept the message, but then internally bin the message, it would be worse. At least in this case, they are bouncing the message. Because of this, the sender is at least aware that the message wasn't delivered.
Also, the author was able to get their mail delivered to a personal gmail.com address. The issue was with a Google Workspace custom email domain. This further makes me think of this as a security/spam related issue. Google is clearly capable of processing the message without a Message-id, they are just refusing for business customers.
My takeaway is that I think that Google is doing the least-wrong thing. And by being explicit in how they are handling it, it at least made the debugging for the author possible.
Also note: in a quick reading of RFC5321 (SMTP), rejecting messages for "policy reasons" is an acceptable outcome. I'm not sure if it applies completely here. The author should probably also be taking into account RFC5321 (SMTP) instead of just 5322 (message format).
Re: Major European payment processor can't send email to Google Workspace users
#70My 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?
So I'm wondering a bit here - I've seen an implementation where emails to send only have html versions, but as part of the sending process the html is run through a Lynx browser process with the -dump command to get the plain text, which is included as the text/plain part of the email. Is there actual value to this? e.g. Is the output of Lynx's text dump better for plain-text email clients than whatever they'd displa…
Some (old?) spam filters may be triggered by html only emails.