Google changes email authentication after spoof shows a bad delivery for UPS Google says it has fixed a flaw that allowed a scammer to impersonate delivery service UPS on Gmail, after the data-hoarding web behemoth labeled the phony email as authentic. The problem stemmed from an issue in an email authentication program called Brand Indicators for Message Identification (BIMI) that aims to protect …
Maybe it's because the article is referencing two different analyses on the issue, but I'm trying to understand why they are calling this a "bug" or "vulnerability" in SPF.
"Too many lookups" is something that has been known about for ages (although most companies probably have no clue when it's happening). The results of the lookup is "Permanent error". I would venture to say you should have a policy to reject email on both fail and permerror SPF lookups, so it would never be delivered. Otherwise, how will someone know their SPF is borked if people treat it like "dunno". Unfortunately, the RFC just leaves the choice up to the receiving end. Barring a complete block, you should at LEAST have increased scrutiny on the email (i.e. don't allow the email to pass DMARC or BIMI in order to call attention to the issue). However, that doesn't seem to be the case for the ups.com email.
In the ups.com email, the headers show SPF passed because Microsoft's servers were authorized to send on their behalf according to the ups.com SPF (they have since changed their SPF). DKIM alignment failed, since it was signed by onmicrosoft.com, but SPF alignment succeeded, thus passing DMARC (a requirement for BIMI). This still isn't a "bug" in SPF; it's doing exactly what it intended: say these servers (e.g. Microsoft) are allowed to send email purported to be from ups.com. The more interesting part is why Microsoft decided to relay an email FROM a "ups.com" address when the SPF check failed (and no DKIM signature). This touches on the problem of SPF as a whole (it breaks relaying). I believe Google only allows relaying FROM domains that you can prove you have some control over.
Ultimately this sounds more like an implementation flaw, not an SPF bug. BIMI is intentionally supposed to be hard to spoof, which is why you need to have everything set up the "proper" way. Requiring DKIM alignment is better in the long run anyway, since that is really hard to spoof.
What happened in Office 365? It sounds like ups.com currently, or at some point, used Office 365 as a mail host leading to Office 365 SPF records. Any Office 365 customer would be able to send from the same servers. This is not a flaw in SPF so much as a scenario it simply was never designed to deal with.
How the bad actors were able to set up to send from ups.com through office 365 is probably a more interesting question.
The inbound email to 365 was spoofed and failed SPF but was not rejected because the account, presumably under the control of the bad actor, had allow listed the bad actor's sending IP. This overrode SPF as they had intended. The message was then relayed straight through MS, UPS had SPF configured with MS IP ranges as valid for that domain and the message was considered good by Google. The supposed bug with Google is that it should be looking deeper into the headers to see that the original inbound message from spoofed UPS to 365 had failed, and they should have enforced the DMARC reject based on that SPF at the previous hop. (I think).
But Google should not be trusting the message headers.
In the scenario you outline, MS have allowed an account to relay for a sender domain that is not validated to the account. This would be a problem in O365, as it allows any customer to masquerade as any other customer!
Now we can argue that Google should have rejected because the DKIM signing key was wrong, but that is a problem with DMARC or BIMI, but if the policy is “one of two”, you can’t fault Google for correctly applying a one of two policy.
Um, it's very likely that it would have been regarded as genuine anyway.
Just this week I got an email posing as from Amazon Prime, nicely alerting me to the fact that my automatic renewal had not gone through and click here to allow us to take care, or I would incur some additional renewal fee of €59.
Initially, the only thing that bugged me was the "additional" renewal fee. I thought to myself : huh ? There is no renewal fee on Prime ! Then my brain kicked into gear and I checked the link and, sure enough, it did not go to any domain registered by Amazon.
Finally, I logged onto my Amazon account and checked : my Prime subscription is in December.
Nice try, guys. For a tenth of a second, you caught me compliant. But that link would have given you away anyway.
But that's only because I always check the link. 90% of people don't (and that's more like 99.9% probably).
So good on Google for correcting the issue. Now someone tell me that changes anything in the Luserverse.
"... Nice try, guys. For a tenth of a second, you caught me ..."
That's because your mind-set is sill in the 1990s. You think "This is probably a genuine email, but let me look for reasons why it might not be".
In the 21st century, instead you need to think "This message is almost certainly fraudulent, let me see if it might just possibly be genuine".
I manage mail servers. More, much more, than 90% of the mail I see is either fraudulent or malicious.
If it gets much worse, email will cease to be a useful medium for anyone. For the majority, I'm sure it's already a liability.
Email is no longer used by may companies. Whenever I want to talk to someone about an issue I have, I have to either ring them up (no thanks, I'll be on hold because just at *that* moment they are incredibly busy, I'm so unlucky), or they'll have some chat bot shit, that, if I type my message and then bugger off for a bit, when I come back they will have responded and hung up the chat.
I love email precisely because it is asynchronous. I can compose my message, taking my time and thinking about it, then send it. I don't have to wait for them to tell me they are ready to talk to me ... NOW.
The 1990s were far better than now.
What actually broke mail are the idiot spam blocking systems that simply blackhole a message they think is spam.
The whole ethos behind SMTP was to ensure a message was delivered - never ACK'ed until fsynced to disk, and a handshaking mechanism that meant that any race conditions would result in duplicate deliveries rather than mail loss.
spam filters buggered all that.
I was corresponding with an occupational therapist working at the local council a while back - it turned out that certain mails were never received. Investigating further there was one particular word that was considered rude (i forget what is was, but the context was innocent) and the whole message was discarded without sender or recipient being made aware...
What happens when a vulnerable patient of hers has email "ignored" the same way?
If you can't reject at source, flag it someway to the recipient. blindly blackholing messages is the sole reason email can no longer be relied on.
(Actually, that's not true. Another is when suspected spam is shoved automatically into a separate folder that no-one ever reads)
Before effective spam filters many simply abandoned email addresses when the spam/non-spam ratio became too high, after a few months.
It's not unlike the current situation with phone numbers and telemarketing, except that it is even more troublesome to give up a phone number.
"Before effective spam filters many simply abandoned email addresses when the spam/non-spam ratio became too high, after a few months."
I have my own domains and use temp email addresses to thwart spam. When that ratio gets to be too much, I delete the address. It also lets me gauge which entities are selling my info to spammers. I have several more permanent email address that I only give to very trusted people. I also have a couple of intermediate addresses that I switch accounts over to when they've shown themselves to be not sold to spammers. If I sign up for something and see a huge influx of spam that company I signed up with is toast. There are far too many options for things these days to put up entities that are "maximizing their income potential through sharing data with marketing partners".
I do similar. I register for all online sites with a unique email address-user based on the site name, to a specific subdomain dedicated to the task.
Basically, *@subdomain.... addresses are directed to me, unless i disable specific email addresses in sendmail.
It's all broken due to extremely differing opinions about what spamming is. Some companies believe in opt-out, and every week has a new promotion that you haven't opted out of yet.
3rd party mail services don't even process refused mail. Why would they? Those refusals might mention awful things about the mail service.
The problem with Google - no, ONE OF the problems with Google - is that when it comes to SPF they haven't got a clue.
I can only quote from a message of mine on May 5th 2023, to a client who was trying to mail a gmail user:
[quote]
The domain "[redacted].co.uk" has not forbidden any address from sending its mail but it also hasn't specifically authorized [redacted]'s
IP addresses to send it. Google is treating the lack of a specific authorization as if it means forbid. According to the specifications
that's wrong, but you try telling Google. Anything.
[/quote]
A short while ago, any mail that I and my BH sent to the few friends who use gmail bounced.
It took a while rubbishing through the badly worded error message but I found that they needed SPF.
Went to Ionos site and yup, there was a note saying that they have recently had this from Google and I had to include SPF entries in our DNS entries.
I’m sure that non technical folk will find this troubling.
Thanks guys.
Same....I use a couple of domains via IONOS for my email and some family members. Recently this gmail bounce thing started, had to figure out the SPF via IONOS, which fortunately they make easy for slightly-technical users but non-techies would have no clue about adding an entry to a DNS, or even what DNS means.
Then a month later, same on another domain. They seem to be rolling it out gradually.
So look at the darned headers! Whenever I get a suspect email I examine its origin that way. All these "authentication" mechanisms primarily add layers of complexity over a quite simple validity check in most cases -- if the first 'received from' domain doesn't match the (free form) 'from' domain, exercise caution. The only problem arises of course where a legitimate corp uses a third party email sender, so I automatically consider such messages suspect.
Another problem (arguably what's at the heart of all email issues) is that the headers can be faked anyway. The headers need not be (and usually aren't) read by the receiving mail server other than perhaps a cursory syntax check.
The mail delivery process is basically 'Hi, my name is Beelzebub. Please chuck these bytes into this/these mailboxes.'.
The sending machine can put anything it wants into these headers. The actual content of the headers is unimportant and ignored by most mail servers. This is why I can send you an email that is apparently addressed to someone completely different and sent from someone fictitious. If you've ever received spam that claims to have been sent by yourself then this is how. The sender just puts your email address into the 'Reply To' or 'From' field and the server doesn't care.
The only sure fire way to know where an email came from and validate the recipient is to monitor the initial handshake process on the server. The SMTP command 'RCPT TO' is what directs the email to an inbox not the 'To' field in the header. And it's only at the point of handshake that you can be sure who the sender is because you know the source IP address and can trace the sender from there.
This is why I continue to run my own mail server. It has the ability to filter on 'RCPT TO' and do other good things at the handshake level. I really can stop the spam at the front gate and senders can't mask their identity. I use a Disposable Email Address system and give every contact their own unique address. In conjunction with RCPT TO filtering I know who is responsible for every email. And if I get spam sent to an address I only gave you then I have the option of blacklisting the address thus stopping future spam and not bothering to issue you with another unique address thus severing our email relationship.
"turned off for the outbound direction"
Probably so. Google appears to be protecting its own customers from scams. Even if those scams originate from a GMail account. If only you would quit fighting the inevitable and sign up for their protection racke.... er, I mean service.
"Google appears to be protecting its own customers from scams. Even if those scams originate from a GMail account. If only you would quit fighting the inevitable and sign up for their protection racke.... er, I mean service."
With very few exceptions, scams involving email are usually done with gMail accounts. Google doesn't give a toss, it's just more data for them to harvest. If you fall for the scams, I expect that Alphagoo does the digital equivalent of placing a chalk mark on the curb in front of your house. I have loads of issue with companies that use O365 for mail services as well as Google for their backend and wind up having to tell some of them they need to contact me using a different mail system if they want messages to get through on a regular basis.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
