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

© 2026 Peter N. M. Hansteen

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 without trackers but classic formatting only 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:

1. 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.

2. 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 teh 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.

3. 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 agains known indicators of spam or malware.

4. 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.

5. If the to address does not match a valid recipient, the message is rejected with a bounce message back to the sending party.

6. 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 they 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 a spam or phishing campaign 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' Spame 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.

---

A Major Mail Provider Demonstrate They Likely Do Not Understand Mail At All is © 2026 Peter N. M. Hansteen (published 2026-01-08)

---

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.

---