A Major Mail Provider Demonstrate They Likely Do Not Understand Mail At All

So it happened again. A major mail provider proved that they do not, in fact, understand how modern email works.

I've been running mail services for longer than I care to remember. It started out back when I was running a small business on the edge of tech, mainly dealing with software localization and documentation writing.

Note: This piece is also available with trackers but nicer formatting here.

The company I had started with a few colleagues were in close cooperation with another business that worked in similar, but not primarily overlapping fields of interest.

Then during the early to mid 1990s, Internet and proper SMTP Internet email became available, and as one did at the time, we set up with a mail service, running at first on an early Red Hat Linux.

After a while we moved to a Debian setup, and over time, unlike most small businesses of the period, chose to not go for a Microsoft solution but rather moved to a setup based on the other free alternatives, with a combination of OpenBSD and FreeBSD for services.

When spam became annoying enough, we configured content filtering of various kinds, which lowered the noise level for a while. Later we discovered that our OpenBSD firewalls could also handle greylisting and tarpitting via spamd, and immediately saw that our mail feed became cleaner yet again.

Those of us who were in the server room when the greylisting was turned on, could not help noticing that the fan noise from the mail server just disappeared.

But one thing we did not get entirely rid of was bounce messages from other sites, directed to user names that had never existed in any of the domains we served. Clearly, one or more groups out there were sending messages with faked addresses in our domains.

So I was very happy when I found that in the OpenBSD 3.3 release, spamd offered a new feature called greytrapping, which meant we could actually put those fake addresses to good use.

From that point on, a high level view of mail delivery to our systems work like this:

When a message arrives, spamd checks whether we have received mail from that host in recent times. Mail from known sending hosts is sent on to the mail server.
If the message comes from a host we have not seen SMTP traffic from earlier, spamd answers one byte per second, finally presenting a Temporary local error, please retry later code and message. The host is greylisted. If the host returns with the same set of sender IP address, from and to addresses, it will be let through. Except in one circumstance which we will come back to very soon.
If the message comes from a known bad sender IP address, spamd answers in a subset of SMTP at a rate of one byte per second, until the sending side gives up.
When a message comes from a greylisted host, spamd checks whether the to address is in the list of spamtraps. If if the message matches this criterion, the sending IP address is added to the the list of hosts with a TRAPPED status and will receive the one byte per second treatment until the sending party gives up. Addresses that enter the spamd-greytrap set stay there until 24 hours after the time of last contact.
If the to address is not in the list of spamtraps, spamd adds the sending IP address to the set of likely valid senders, and passes the message on the real mail server.
The real mail server performs various checks on incoming mail, including whether the sending domain has valid SPF, DKIM and DMARC information and several kinds checks of message contents against known indicators of spam or malware.
If the message passes all those validity and content checks, the mail server check whether the to address matches a valid recipient in the domains we handle.
If the to address does not match a valid recipient, the message is rejected with a bounce message back to the sending party.
If the to address does match a valid recipient, the message is delivered according to the configuration that is in place for that recipient.

The main difference between this setup and any mail server you will have heard about, is that we have a list of spamtraps. The source for spamtraps was originally the invalid addresses that turned up in our mail server logs.

Later, with greylisting in place, the obvious selection criterion was checking the greylist for addresses that did not match any local recipient or an existing spamtrap. Over time the number and kinds of sources expanded a bit. You can read all you want about that and more in the retrospective article Eighteen Years of Greytrapping - Is the Weirdness Finally Paying Off?

I have an hourly cron job that runs a script that exports the list of trapped IP addresses for use elsewhere and produces a report of various useful items, including a list of possible new spamtraps, extracted from the greylist.

The overnight batch on January 8th, 2026 looked like this:

fuchigamikamogawa522@bsdly.net itsukiishibashimitaka@bsdly.net kinoshitario0310@bsdly.net kuromotoasuka_1007@bsdly.net kyokomatsudakita@bsdly.net motohashi_katsuyama@bsdly.net namikiakari-funabashi@bsdly.net namikidaisukeyamagata@bsdly.net nomurajunichi_1958@bsdly.net numanoenergy@bsdly.net otaniasami@bsdly.net rikoizawa2004@bsdly.net sakakihifumi@bsdly.net seoreina-1991@bsdly.net shimamura_asahikawa@bsdly.net sugimototaro.0321@bsdly.net teshigawaraishikawa@bsdly.net tokitakota.1968@bsdly.net tsuboneyuji_mori@bsdly.net ueki-miyagi633@bsdly.net yamabenoboru@bsdly.net

The local parts or user names are not what you would expect to find in a business based in Norway.

But these Japanese-sounding names are quite typical of the backscatter we have been seeing here during the last two or three years. Most likely somebody is running spam or phishing campaigns aimed at Japanese users.

The bounce messages do not ever reach an inbox, but they do turn up in the greylist dump in the hourly message . There, the <> in the fourth column reveals that the messages were indeed bounce messages.

The afternoon batch looked similar:

aoki-1990600@bsdly.net fumiakihachiya0827@bsdly.net hachiyaakira-stormchaser@bsdly.net hanamurachihiro2000@bsdly.net isaacclark.sarahclark@www.bsdly.net izawanaoki0819@bsdly.net junanzai0902@bsdly.net kagawa.1965@bsdly.net kashiwagi1967@bsdly.net kawamurasoma1971@bsdly.net kenmiyagawa1953@bsdly.net kodama_1985@bsdly.net kusunokiotsu@bsdly.net liammartin.norakumar@lfja.org machiasuka_1977@bsdly.net masuda1955@bsdly.net matsuoka-1976@bsdly.net monmagenji654@bsdly.net mutojunichi-noon@bsdly.net nakaya-2017@bsdly.net oscartanaka.zoeevans@lfja.org rukanakagome1981@bsdly.net ryuseiterasawa2021@bsdly.net shinjiohno.futtsu@bsdly.net tabatayusuke_0302@bsdly.net tamuraryuji1995@bsdly.net tsukuda2016@bsdly.net usuda.ishikawa.star@bsdly.net yoshidakatsuo@bsdly.net yukitakahagi94770@bsdly.net

The addresses in both of these batches were added to our spamtraps, affectionately known as our imaginary friends, along with a number of synthetic entries as described in the longer article Eighteen Years of Greytrapping - Is the Weirdness Finally Paying Off?.

But that day, after processing new spamtraps and a bit of overnight mail, I sent a message to a business contact of mine that uses a Google as their mail service provider. That produced a bounce message, some of which is quoted in this graphic:

I had put my own gmail.com address on Cc:, in part due to various earlier episodes with that provider. The diagnostic was the same for the other recipients.

This means that after several years of mostly managing to deliver messages sent from our systems to their intended recipients in Google managed domains (at random times deciding to put mail from here in their users' Spam folders), somebody decided it was time to disregard our domains' published SPF and DMARC information.

Their "very low reputation of the sending domain" is is likely down to a very poor understanding of how modern mail delivery works.

More likely than not, the volume of messages sent with faked sender addresses claiming to be from our domains and a source IP address in the great elsewhere is vastly larger than the actually valid messages sent from valid users, all of which will come from the hosts listed in our published records.

The existence of spamtraps should not be a surprise either, after all we have been doing greytrapping for more than eighteen years.

I would posit that this is a mail services provider that has demonstrated that they do not, in fact, understand SMTP mail at all.

Fortunately, posting the data and a description of the incident to a mailing list for mail administrators indicates that persons who work for that operator read that list, since the problem lessened a bit a few hours later. My messages now only land in the recipients' Spam folders.

I would like to invite a debate about incidents of this type. The big operators can be quite nasty to smaller players, as we can see from this episode and the earlier one you can find by following links in this article.

What are the sensible standards of behavior (aka netizenship) to expect from mail service providers?

Should, for example, we consider making the large operators (or smaller ones, for that matter) liable for damages for mishandling their service offerings like this?

Followup in comments to this article (where possible) or to the social media post that lead you to find this article.

Update 2026-01-09: One small batch of data might be of interest to my core readership. The output of a grep for "Unknown user" in the as-yet-unrotated mail server log is preserved in this file. My reading of this is that even the big names do not actually value their SPF/DMARC checks much at all.

Update 2026-01-10: A few hours after I had posted to the limited-distribution mailing lists for mail operators, and soon enough after I had published the original version of this article that it likely they did not read it yet, I was contacted by people who were plausibly claiming to be close to the actual developement and maintenance of the gmail codebase.

My impression, or at least the way I read what was in that communication, is that

Gmail is a large code base that has been evolving over a long time
The system is complicated enough and with enough factors (in the hundreds) involved that feeding the same message through the system several times is likely to produce different results each time
The messages the system produces for external parties to see are unspecific at best and may in fact point to factors other than those that actually determined the pass/no pass decision
The code has passed through many hands, and I at least get the impression that nobody currently there can honestly say they understand all aspects of the system

Despite all of this, they trust the system absolutely, claiming that it has a negligible false positive rate.

The last bit I at least think is a delusion that is sustained by the fact that they have made it pretty much impossible to file a problem report. It likely is easier for paying customers, but the only way in I have found is to post my gripes in public.

And yes, for every incident (there have been quite a few over the years) I have used side channels to contact my GOOG-using connections and ask them to file a problem report with as much details as possible. That seems to help, sometimes.

I had thought up a really snappy and harsh one-liner to characterize all of this, but I think I'll save that for another occasion.

Max Stucchi and I will be giving a PF tutorial at AsiaBSDC0n 2026, and I welcome your questions now that I'm revising the material for that session. See this blog post for some ideas.

For more information about the BSD conferences, see What is BSD? Come to a conference to find out! (also tracked).

For a broader overview and retrospective of mail and greytrapping, you may be interested in reading Eighteen Years of Greytrapping - Is the Weirdness Finally Paying Off?, which links to this piece and a number of other related resources.

You might also be interested in reading selected pieces via That Grumpy BSD Guy: A Short Reading List (also here).

Separately, pre-orders of The Book of PF, 4th edition are now open. For a little background, see the blog post Yes, The Book of PF, 4th Edition Is Coming Soon (also here). The latest information I have is that physical copies should be ready to ship by the end of January 2026.