A friend was not receiving Facebook SMS two factor authentication codes on his iPhone. I removed all his blocked numbers and he received the code. We assume he accidentally blocked the number Facebook uses to send SMS codes.
You can see blocked numbers in Settings:Phone:Blocked Contacts (it's actually a list of blocked numbers, not a list of blocked Contacts). If iCloud sync is working you see the same list in Messages on macOS.
Recently more of the email that bypasses Gmail's spam filters has a return address with the suffix "*.xt.local". I've been able to find low quality posts about this issue from at least 2017, but in the past few months the volume has increased significantly.
One source of the emails has been spammer customers of Salesforce.
I'd previously marked one of these as spam, when I view it from inbox Google shows me:
"You unsubscribed from <100018015.xt.local>"
If I try to reply I see:
"reply-fec215727d600275-157_HTML-100984021-100022017-13039@e.sixt.com"
If I choose to filter I get this as a filter criteria
Has the words: list:(<100018015.xt.local>)
An expert on spam filtering tells me xt.local is the name of an email list.
I've added xt.local to Gmail's (increasingly obscure) filters as an automatic delete. I currently have it in there as a return address but if that doesn't work I'll try it as a label.
Google's 'show original' extracts the following header information:
....
From: SIXT <info@e.sixt.com>
To: ********
Subject: Start your week in style! Up to 30% discount on midweek rentals
SPF: PASS with IP 13.111.115.170 Learn more
DKIM: 'PASS' with domain e.sixt.com Learn more
DMARC: 'PASS' Learn more
I'll update this post if filtering on xt.local as the sender address doesn't work.
PS. When I searched on this, even using Kagi (which is looking to be a very interesting search engine if they can stay in business), I found very few useful posts. Even five years ago there would have been dozens. Something rather important has been broken.
Send an email message to someone who is using Gmail or Google Workspace. (You can't verify DKIM is on by sending yourself a test message.)
In the message header, look for Authentication-Results. Receiving services use different formats for incoming message headers, however the DKIM results should say something like DKIM=pass or DKIM=OK.If the message header doesn't include a line about DKIM, messages sent from your domain aren't signed with DKIM.
When I looked at view original sent form Emily's account to my personal gmail account I didn't see DKIM=pass or DKIM=OK but I did see two entries starting with:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
More importantly when I scrolled up a bit (this is in Gmail View Original) I saw a header that's interpreting the email headers (I think this might be a newer feature):
Message ID ....
Created at: Mon, Mar 13, 2023 at 2:59 PM (Delivered after 12 seconds)
From: Emily ....
To: John ...
Subject: test DKIM content
SPF: NEUTRAL with IP ...
DKIM: 'PASS' with domain ...
You can also paste the "original message" headers into toolbox.googleapps.com/apps/messageheader/. That gave similar results.
When I tested on a second family domain that did NOT have DNS TXT entry for DKIM it showed as DKIM 'PASS" in the email header interpretation with an odd domain string -- BUT in Google Apps it showed as NOT authenticating. I cannot explain this.
Once I updated the DNS TXT DKIM entry for that domain and allowed a few minutes for propagation it did show in the Google Apps admin console as authenticating with DKIM and the headers showed the correct domain name.
DH's note on SPF records says they cannot be updated if we are using Google Workspace. This is new since 2018 and I think that's correct.
I do not understand why it took Apple so long to do basic management of text message (SMS) spam. I don't understand why the solution appeared over two releases. I don't get why the implementation is so obscure. And I don't get why I had to write this; even knowing the two necessary settings I can't find a good article on it. Apple's own documentation doesn't mention disabling notifications.
Anyway, as of iOS 15 you can finally turn off notifications for SMS sent from an unrecognized number. This is in addition to iOS 14 enabling sorting of unrecognized number SMS into a separate tab. (I think iOS 13 you could only filter iMessages, which is basically useless.)
First enable "Filter Unknown Senders". Unrecognized SMS messages go into a separate tab.
Dreamhost writes about SPF:
… Mail servers that receive an email for delivery can check SPF by comparing the sending server’s IP address against the email's envelope sender's SPF DNS record. If the email was sent from a server that is not included in that SPF record, the email is more likely to be spoofed or untrustworthy. The receiving mail server may handle the email differently because of the SPF failure, such as marking the email as spam or rejecting the email…
and
What SPF records do I use? – DreamHost
If you’re hosting your email at DreamHost, no changes need to be made to your SPF records. DreamHost’s SPF records are generated automatically and should work without any issues or additional changes.
IP's in DreamHost’s SPF records include mail servers and the relay machine IP addresses.
Except this isn’t true. When I was investigating my family’s Google email Hell I found that emails sent from DH Webmail didn’t have SFP records in the header. I tested using mxtoolbox.com, Kitterman, and by inspecting emails in Gmail using the ‘view original’ option. I also directly inspected my DNS settings. No SFP.
When I asked DH tech support admitted their documentation was wrong and responded (emphases mine):
If it were, you'd see the SPF setup on the 'Manage Domains' > 'DNS' pageby default for every domain hosting mail with us along with the DKIM
that's already there, but SPF is NOT set by default (at this time).
… we should start setting it by default, so that info above may be accurate in the future. We’re doing a lot with emails right now, which is still mostly in the discussion phase, so this is likely something that’ll come up as well what with various hosts starting to strengthen their incoming filters to help stop spam.”For the domain in question, I’ve added the record for you through the 'Manage Domains' > 'DNS' page as a TXT record:
… We have now added the TXT record for .faughnan.com with value v=spf1 include:netblocks.dreamhost.com. Our DNS servers will start serving this
record within a couple of minutes.
My DNS records now show an SFP TXT record:
v=spf1 include:netblocks.dreamhost.com
Unfortunately adding the SPF didn’t help with Google treating my DH redirects as spam. I have a hunch those come from DH’s own SMTP service (homiemail) and that service might have a reputational issue with Google, but I don’t really know what’s going on. I don’t think anyone does any more.
What about DKIM?
DH claims DKIM is set automatically and I can confirm that works, at least for a domain that was relatively recently added to DH. On the other hand when I examine that domain’s DNS settings I see several records not in my older domain. I wonder if DH has never updated DNS settings for older domains, such that they are now obsolete. OTOH, even for a new domain there were no SPF records.
And then there’s Google domain verification (postmaster services). I turned those on my adding their key to a TXT field, but a few days later it wasn’t there any more. I assume DH removed it. I’m kind of losing confidence in Dreamhost.
… we’re living in a time when algorithmic software is just good enough to eat the world and still bad enough to be endlessly frustrating. (Daniel Genser, via Twitter)
A few days ago I sent an email to Emily and a few seconds later this came back:
Mail Delivery System <MAILER-DAEMON@homiemail-mx1.g.dreamhost.com>
Tue, May 8, 9:52 PM (4 days ago)This is the mail system at host homiemail-mx1.g.dreamhost.com.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.…
DreamHost Email Support
<emily@googleappdomain.com> (expanded from <emily@redirectemail.com>): host
ASPMX.L.GOOGLE.com[173.194.202 .27] said: 550-5.7.1 [208.97.132.209 12]
Our system has detected that this message is 550-5.7.1 likely unsolicited
mail. To reduce the amount of spam sent to Gmail, 550-5.7.1 this message
has been blocked. Please visit 550-5.7.1
https://support.google.com/mai l/?p=UnsolicitedMessageError 550 5.7.1 for
more information. q3-v6si11849599pgn.272 - gsmtp (in reply to end of DATA
command)
Google had sent me to email Hell. Everything I sent to Emily was rejected. It was the same story with emails sent to my children. Whatever I sent, Google rejected.
I think the problem, as far as Google was concerned, was that I was using redirects. This is old net tech. If you own a domain, say “kateva.org”, your hosting service will usually let you define as many redirect “email addresses” in the domain as you might want. They aren’t real email addresses though, they’re redirects. You have to define a true email recipient for each one.
Google didn’t see the email I sent Emily as coming from my personal gmail account, it saw it as coming from the SMTP service that works with my domain (which I’ll call “kateva.org"); in this case homiemail-mx1.g.dreamhost.com. It appears either my domain, or that sending service, had bad Google-karma [1]. Google sent the rejection to “homiemail” (I think!) and homiemail sent it to me.
We were in trouble. It was likely that email sent to our family members was going to be bouncing back in a very confusing way.
I tested sending from various email addresses and using various software (web client vs. iOS Mail, etc) to see which was rejected and which accepted:
| Sender | Redirect | Result |
|---|---|---|
| GSuite (web client) | Yes | Success |
| Yahoo (web client) | Yes | Success |
| Gmail (web client) | Yes | Success |
| GSuite (macOS mail, iOS mail) | Yes | Success |
| Gmail (macOS mail, iOS mail) | Yes | FAIL |
| Gmail (macOS mail, iOS mail) | NO | Success |
It turned out my mail was only hitting Google’s spam threshold when I sent it from my personal Gmail (not GSuite email) using iOS or macOS Mail. Everything else worked, including using my personal Gmail by web interface.
No, I don’t understand what’s happening here. I can speculate that Google rates sending services roughly as follows: GSuite_web > Gmail_web, Yahoo_web > GSuite_client > Gmail_client. The combination of Gmail_client (macOS Mail) and the redirect dropped my email score below Google’s internal cutoff.
There’s not much to do about this. It’s not like Google is going to help. I was on my own and we were in trouble.
The first thing I did was change the redirects to send all the mail to an old school Dreamhost local webmail box. That stopped the bouncing. I could forward from that box to my gmail and reroute important emails manually to other addresses for Emily and the kids.
Next I discovered, contrary to their documentation, that Dreamhost had not enabled DKIM or SFP on my domain. I fixed that (separate post pending) to see if it would improve the reputation score for my domain but it had no effect. I suspect the reputation that mattered was that of homiemail-mx1.g.dreamhost.com.
That left me with these options …
Dreamhost recommended the 1.2 (second). But I had a third option…
… even though I’d not used it, the problem domain (“kateva.org”) had an old legacy GSuite. I went into that GSuite, defined an account for Emily and kids, and then switched Dreamhost MX to use the GSuite email rather than DH email [2]. I had lost some faith in DreamHost by that point and I figured that since Google rules the net I was better off inside their castle.
And that’s where we are at the moment.
One more weird thing. For 2-3 family members I received a notice that a non-apps Gmail account already existed for them. I didn’t create those accounts but maybe my kids did? (It’s complicated, but somehow when I did Google Voice for them it did … something … brain shutting down ….) Apparently Google lets one do this! They wouldn’t have received email though, DNS records were using DreamHost MX redirects. If you own a domain, and create Google Apps account that matches the existing address, it gets renamed to something like “username%domainname@gtempaccount.com” email. Wow. [3]
It’s Google’s world, we just play in it.
Oh — and don’t use redirects. Google doesn’t approve.
- fn -
[1] Dreamhost denies that they’re in any kind of trouble with Google — but really, how would anyone know. Maybe it was my domain that Google didn’t like — we get a lot of spam and in this setup all that spam would seem to be coming from my domain.
[2] This wipes out all the past redirects. GSuite supported aliases so I moved them into there. Fortunately I’d saved the redirect records before making the MX switch.
[3] Google has an article on conflicting accounts, here is how they are resolved. I think Google Voice was the primary route for creating conflicting accounts — an artifact of how Google switched Voice credential systems post acquisition.
I got a notice from Google yesterday. tech.kateva.org had been quarantined as a phishing vector. Visitors would be warned away. I had a short time to fix the affected page that was listed below …
But there was nothing there. Same thing with a link to a downloadable spreadsheet of issues. That was empty too.
Elsewhere in the message a page was identified. It sure looked benign, the only link was to an Apple support site. It’s a (Google) blogger site and all the widgets were default Blogger. No extra HTML. No comments.
Also, despite Google’s warning, the blog was not quarantined.
A puzzle.
Oh, I left something out. The day before a published spam comment showed up in my comment tracking feed. I get a few spam comments every day or two, but this was the first published one in a while. I went to delete it … but by the time I got to Blogger’s post management menu the comment was gone.
This is what I think happened:
I changed comments on the blog to require authorization at all times — no two week window for authenticated users. Clearly authentication is no longer a sufficient barrier. I don’t want phishing attacks on my blog, and I don’t want to get quarantined.
This reminds me what a strange fish Blogger is. It works fairly well, though there’s a longstanding problem with CR/LF handling that reminds me too much of DOS 2.1. It gets very few, but still some, updates. Google has switched their blogs off Blogger, but they haven’t used their new proprietary RSS/Blog platform to replace Blogger. Blogger is neither dead nor alive, and Google RSS is similarly quantum.
This one amused me.
I have an email address in one of my domains that redirects to an immutable long-random-username address assigned by Appigo. Messages to that address create tasks on Appigo’s ToDo.app [1]. Today when I opened ToDo.app I had a task that included a phishing attack link. The “Dear xxx” introduction included the username portion of my redirect task.
This clearly wasn’t a specific ToDo.app phishing attack; it was a routine email phishing attack. Gmail would have sent it directly to spam, but of course this route bypassed spam filtering. Having a phishing attack appear on my task lists was an emergent result of using a “secret” email address as a data interface.
The good news is that the email redirection I used is also a form of defense. Appigo doesn’t provide a way to change their secret email address (not smart of them), but since I created a short memorable version their immutable “backdoor” was not exposed. I can change the redirect address I control.
Intelligent systems are rather hard to secure. Which is why the Internet of Things is a mistake. Make no system smarter than it needs to be…
[1] I use this app extensively on iOS and OS X, but I don’t recommend it because there’s no data export or archiving support. Of course most of the competition are no better, but OmniFocus and Toodledo provide export.
