The Rest Is Trash

© 2026 Peter N. M. Hansteen

We are now halfway through the nineteenth year of greytrapping, still tracking and collecting from the wealth of imbecility out there

My logs tell me that in early September of 2025, I added the following entries to the list of spamtraps (or raw version)

!!!!!!!!der!rest!ist!muell!@bsdly.net
!!!!!!!!el!resto!es!basura!@bsdly.net
!!!!!!!!the!rest!is!trash!@bsdly.net
    

on a whim and to emphasize to anyone who would actually care to read any part of the file that the content is, for most purposes, utterly worthless.

Note: This piece is also available without trackers but classic formatting only here.

Planting a clue that obvious may or may not have helped somebody out there, but it felt somehow appropriate. And while writing this article, I added a French equivalent for those who would feel that one was needed.

As I have mentioned earlier, there are a number of ways to find potential spamtrap material. In the early days, I simply extracted entries from the mail server logs with some very crude regular expression match using grep on the log files.

Later I set up to extract from the spamd greylist instead. That turned out to be a little shortsighted, since it would not then catch the attempted deliveries from a host that had already entered the blocklist. That thought only struck me again some years later, and in the 2022 piece Harvesting the Noise While it's Fresh, Revisited (also here) I run through how I amended the collection method a little.

The retrospective piece Eighteen Years of Greytrapping - Is the Weirdness Finally Paying Off? (also here) offers descriptions of a few other methods of creating spamtrap entries.

Then in the early days of January 2026, another episode involving a mail operator you will have heard about led me to write A Major Mail Provider Demonstrate They Likely Do Not Understand Mail At All (also here).

That episode also led me to realize that with a significant part of the traffic from at least that operator coming in over IPv6 or from a set of pre-cleared hosts such as the mail exchangers of the too big to block operators, there would be nothing logged by spamd anyway, so I set about collecting yet again candidate spamtraps from the real mailserver logs.

It turned out that by not looking at delivery attempts via IPv6, I had indeed been missing quite a significant number of potential imaginary friends.

As a result of the expanded scope of my noise harvesting, combined with some light massaging of the finds using tools such as rot13 and rev, the total number of added spamtraps for the month of January 2026 was

5665771

a total of five million, six hundred and sixty-five thousand, seven hundred and seventy-one added, so the total by end of January 2026 was more than twenty-two and a half million.

I will keep updating the retrospective piece Eighteen Years of Greytrapping - Is the Weirdness Finally Paying Off? (also here) with monthly numbers, and those who are interested can even follow the progress by monitoring the files in the log directory.

And since I know some of my returning readers feel that a greytrapping article is not complete without a graph, I have made one for the year so far,

The data that went into producing the graph is available as 2026-traplistcounts.txt.

I take the numbers so far as an indication that the trend towards fewer routable IPv4 addresses are in play continues, with some traffic moving to IPv6 while an increasing number of spam senders are likely behind NAT, carrier grade or otherwise.

But there is another annoying phenomenon that turns up occasionally. From this perch it looks like one or more somebots or somebodies mistake a greylisting and greytrapping spamd for an open relay, and something like this happens.

A host somewhere (in this case apparently in China) tries to relay via my setup, in this case using a significant subset of the spamtraps as their From address.

Some of these episodes have come with a rate of new connections and sheer number of attempts that it leads me to think there may be more than one host actually active, likely behind a NAT device.

One recent episode annoyed me enough that it had me toy with appending state tracking with overload to the pf.conf rule that feeds our spamd, so the rule would be

---

pass in on egress inet proto tcp from any to any port smtp \
divert-to 127.0.0.1 port spamd flags S/SA keep state \
(max-src-conn 1200, max-src-conn-rate 255/10, overload <webtrash> flush global, pflow)

---

which in means that any spam source that insists on trying to fill our state table will earn themselves an entry in the <webtrash> table, to be blocked by us and consumers of the exported blocklist for the next six weeks.

This has the slight disadvantage of letting the spamd-greytrap entry expire 24 hours later, but on the other hand the rules in place here and possibly other places mean that the host will not be able to communicate at all with any system that uses our exported blocklists for at least six weeks.

But of course, our log files will be incrementally quieter for that period of time.

If you have any comments you want to share, please let me know either in comments to this piece (where available) or followups to the post where you found this article referenced.

Update 2026-02-07: I added a few more translations of the phrase "the rest is trash", prepended with !!!!!!!! and interspersed with further !s where I it seemed appropriate. If you feel more languages need to be covered, please let me know in comments or send me an email, with the desired translation.

---

In other news, The Book of PF, 4th edition is inching nearer to delivery in physical form. See the earlier piece Yes, The Book of PF, 4th Edition Is Coming Soon (also here) for the story of why that edition needed to exist.

The next scheduled Network Management with the OpenBSD Packet Filter Toolset session will be March 19, 2026 at AsiaBSDCon 2026 in Taipei, Taiwan.

Papers and other sessions selection for BSDCan 2026 should be complete very soon after this piece has been published, so if you submitted, look for incoming BSDCan mail.

The call for papers be for EuroBSDcon 2026 will open March 1st, 2026 and run until June 20th.

If you are interested in coming to a regional BSD conference as a speaker, volunteer or other participant, see What is BSD? Come to a conference to find out! (also here) for some information.

---

The Rest Is Trash is © 2026 Peter N. M. Hansteen (published 2026-02-01)

---

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

Eighteen Years of Greytrapping - Is the Weirdness Finally Paying Off?

© 2025 Peter N. M. Hansteen

With the imaginary friends, also known as spamtraps, now more numerous than the inhabitants of their virtual landlord's home country, a greytrapping retrospective is in order.

Friends, it finally happened. On August 7th, 2025, the number of spamtraps intended to woo the unwary spammer rolled past the number of inhabitants in my home country of Norway, as tallied by the official statistics compiled by Statistisk Sentralbyrå, also known as Statistics Norway.

After the morning run that day, the number of spamtraps (imaginary friends) stood at 5620384, inching past the country's total population of 5601049. And yes, the first number is likely to have increased when you read this. Under normal circumstances, the second will likely move a bit in the near future too. To mark the occasion, I present to you the retrospective that some correspondents have been asking for in response to some recent mail related articles of mine.

The Experiment Started in 2007

Greytrapping at nxdomain.no, also known as bsdly.net and a few other domain names, has been a long running experiment. I had been running a mail service for my own and my colleagues' benefit for some years already when I converted that setup stepwise from a Debian Linux setup to one involving OpenBSD hosts as the outer line of defense and a mix of FreeBSD, OpenBSD and other hosts in an evironment not unlike what is described in some of the rather basic configurations described early on in the PF tutorial and later The Book of PF.

Soon after converting the outer defense at that site to an OpenBSD one running a basic PF ruleset, I introduced the then blocklist-importing and greylisting only spamd, and experienced (as described elsewhere) that the fan noise coming from the mail server, obviously burdened by performing content filtering, just stopped immediately, only to occasionally to rise just a quiet murmor for the rest of that server's service life.

---

Note: This piece is also available without trackers but classic formatting only here.

---

I did not retain records of when I did that conversion, but my original PF presentation slides from January 2005 describes a spamd setup with greylisting as well as imported lists from spews and spamhaus, which is a strong indication that I had had that running for a while at that point.

Greytrapping was only introduced a little later, but when the feature became available I was ready and eager to put it into production as soon as at all possible. I went on to initiate the greytrapping experiment some time in 2007 and announced to the world in the article Hey, spammer! Here's a list for you! (also here) on July 9, 2007.

Unfortunately, or some would say fortunately, we have not been able to preserve all logs and records, but enough survives that we can sense the general thread and trends until we can get into the details of what we do have available from the last handful of years.

In Retrospect, What Changed Over the Years?

Looking back to the mid-noughties, the most significant change I see is that back then, people did this sort of thing.

Even for small organizations like the company I was attached to then, it was entirely normal to set up their own, in-house mail service as soon as they had some sort of Internet connectivity available.

In the years since then, the Internet in general, and SMTP email in particular, has been centralized to a degree we would not have considered even imaginable back in the mid-noughties.

We call it The Cloud, but as we all know it's really about running your stuff on other people's computers, and in the email case, the centralization is even more extreme.

In some of the field notes and articles linked at the end of this piece you will find mention of the major players in hosted or cloud email field and the fallout from their policies. Those policies and the companies' actions hint strongly that they really think that unless you are them, you have no business running a mail service.

So if it is not clear already, this is a piece that is written for people who either run their own mail service or are considering setting up one, as well as people in their immediate surroundings.

If your perspective on email is "how can I do $THING in Outlook?" or similar, this is really not for you, but you are of course welcome to read on for entertainment and/or enlightenment value, if such is to be found.

If you are considering setting up your own mail service, my main recommendation to you, after you have skimmed this piece and a selection of the linked resources, is to get Michael W. Lucas' 2024 book Run Your Own Mail Server, read it from cover to cover, and do what the man says. That really is the best book on the subject currently available, and it is recent enough to not yet be outdated.

What I saw as the main attraction of the greylisting and greytrapping combo back in the day and even still do, was and is that a set of actuallly quite simple network-level tricks and a tending-towards-pedantic interpretation of the SMTP protocol specification could have such a dramatic effect on the amount of work involved in running a sane mail service.

With a greytrapping spamd and a mail service that would utilize the content filtering setup du jour, my colleagues in the various organizations where we had these setups in place never saw the need to even consider listening to sales pitches for other offerings.

The early field notes and articles very much reflect that situation. We were quite enthusiastic about what we had running. What we had was cheap and reliable, and when there was a need to debug something, we would either point to the other party's configuration fumble or do such things as slowly come to the realization that not all senders play well with greylisting (also here).

I Hear You Say It's Good, But You're Weird Anyway

Over the years my experience of advocating both OpenBSD or FreeBSD as systems to use in general and implementing a greylisting and trapping spamd specifically, more often than not the attitude I would need to try turning around would typically be along the lines of I hear you say it's all good, but you're weird anyway.

In retrospect some of that may have come from me generally using various versions of the somewhat lengthy Effective Spam and Malware Countermeasures - Network Noise Reduction Using Free Tools (also here), sometimes supplemented with In The Name Of Sane Email: Setting Up OpenBSD's spamd(8) With Secondary MXes In Play - A Full Recipe (also here) more or less as promotional material. Both texts have to my mind stood up well over the years and are potentially useful for the right audience, but may not have been quite appropriate in a sales context.

There would be some update here and there, and questions I got during tutorial sessions and via various online channels indicate that people were setting up similar setups to what I have described there, and the various exported blocklists (see eg Badness, Enumerated by Robots (also here)) are quite popular downloads both at the primary and the mirror site.

Over the years there would be some odd episodes, sometimes involving the big players, with a piece such as Does Your Email Provider Know What A "Joejob" Is? (also here) a prime example of behavior I personally do not appreciate experiencing from anyone. On the other hand, in A Life Lesson in Mishandling SMTP Sender Verification (also here) we see an example of a different big player actually contributing well to resolving a puzzling situation.

In addition to the big players, we have of course also at times ran into less pleaseant encounters with not-exactly-captains-of-industry too. An early example was that in 2008, the notion that a challenge-response setup could be an effective antispam mechanism was apparently cultivated by some. In the field note I challenge your response, backscatterer (tracked only, sorry) we see how that went.

If you skim the field notes and articles linked at the end of this piece, you will find that there is, in fact, no end of weirdness in the email business. But one case involving what we must assume is pretty much a bit player had me write up Twenty-plus years on, SMTP callbacks are still pointless and need to die (also here). The TL;DR of that one is that what could have seemed like a bright idea way back when turned out not to be, but in some corners of the internet there are still true believers who can simply not be persuaded to change course even a little.

After a while, I found that though odd episodes did occur, I found it harder to make the writeups interesting and fun to read. A case in point is the year 2019, where at the very end of the year I finally forced myself to write that my only article of the year, The Year 2019 in Review: This Was, Once Again, Weirder Than the Last One (also here). That year had had its share of oddities, including a totally bizarre amount of backscatter from what must have been one or more phishing campaigns aimed at Chinese users. I found that episode hilarious myself, and while it prompted me to automate the spamtrap harvesting a bit, I tried and failed over and over to write what I thought would be a readable and enjoyable article about it.

Actually Running the Thing, and Finding Imaginary Friends

The day to day operations of the greytrapping is quite unremarkable, really. The script that dumps the trapped IP addresses at ten past every hour also presents me with a list of candidate spamtraps -- addresses in our domains currently in the the greylist that do not match any existing valid address or spamtrap, and I add those when I have the time at quasi-random points during the day.

The dump of trapped IP addresses is totally automated, and expiry is 24 hours. In 2013 I wrote a piece called Maintaining A Publicly Available Blacklist - Mechanisms And Principles (also here) that lays out the process in hopefully understandable terms. There is of course also the short version available on the website.

Over time we went from simply collecting from the greylist to also fishing out local parts from the logs of failed logon attempts to services such as ssh and (the obsolete, horrible) pop3.

A little while later it occured to me that it would perhaps be useful to make a record of when each spamtrap entry was added. History starts 2017-05-20, whatever spamtraps can not be found in this data set is assumed to have been added before that date, and reconstructing earlier history of the data would take more time and effort than I have any motivation to expend on the task.

The first partial year's data are, summarized:

New traps per month, 2017
Month	Total	SMTP	SSH	POP3	Other
May	159	49	110	0	0
June	275	48	213	14	0
July	811	144	667	0	0
August	486	447	38	1	0
September	-	-	-	-	-
October	886	513	367	6	0
November	825	57	768	0	0
December	299	91	208	0	0

From that year, the first aricle A New Year, a New Round of pop3 Gropers from China (also here) (January 9, 2017) was written before the date added data started, while the episode described in Twenty-plus years on, SMTP callbacks are still pointless and need to die (also here) (August 27, 2017) more likely than not produced more spamtraps around the time the article was written.

For 2018, we have the first in the series of a full year's data on traps added:

New traps per month, 2018
Month	Total	SMTP	SSH	POP3	Other
January	304	172	132	0	0
February	228	72	148	2	0
March	160	73	87	0	0
April	102	84	18	0	0
May	12206	811	113701)	22	32)
June	146	26	59	61	0
July	358	248	26	84	0
August	359	125	69	165	0
September	-	-	-	-	-
October	671	241	413	17	0
November	311	297	12	0	23)
December	1038	116	922	0	0

---

¹⁾ From the Hail Mary Cloud data set
²⁾ IMAP
³⁾ JOKE (see the data)

---

From June 2018 onwards, we have hourly data on the number of hosts trapped in our spamd-greytrap, in a form that is relatively easy to graph:

The data that went into producing the graph is available as 2018-traplistcounts.txt.

The articles from 2018 include A Life Lesson in Mishandling SMTP Sender Verification (also here) (February 17, 2018) with that life lesson, while the next two show that I felt a need to explain exactly what that blocklist producing thing was about, first with Badness, Enumerated by Robots (also here) (August 13, 2018) and the followup Goodness, Enumerated by Robots. Or, Handling Those Who Do Not Play Well With Greylisting (also here) (November 4, 2018) which really only goes to show that I was starting to contemplate converting my setup to use OpenBSD's own OpenSMTPD -- part of the base system -- rather than trusty old exim.

The 2019 spamtraps added data shows shows again, just how weird that year was -- see The Year 2019 in Review: This Was, Once Again, Weirder Than the Last One (also here) (December 28, 2019):

New traps per month, 2019
Month	Total	SMTP	SSH	POP3	Other
January	1829	192	1636	0	14)
February	19644	18782	860	0	25)
March	58005	57186	819	0	0
April	53856	52563	1290	3	0
May	2315	350	1964	1	0
June	3164	312	2852	0	0
July	1058	434	618	6	0
August	1229	331	898	0	0
September	-	-	-	-	-
October	11016	630	10385	1	0
November	11119	222	10897	0	0
December	19304	208	19096	0	0

---

⁴⁾ ARTICLE (see the data)
⁵⁾ JOKE (see the data)

---

The year 2019 is the oldest preserved data set of number of hosts in our spamd-greytrap that covers an entire year, which in turn gives us this diagram of the year:

The data that went into producing the graph is available as 2019-traplistcounts.txt.

The lockdown year 2020 again did not see much article activity, but after seeing the N!th wankstortion campaign aimed at a large subset of our imaginary friends, I wrote a rant-ish article about it: The 'sextortion' Scams: The Numbers Show That What We Have Is A Failure Of Education (also here) (February 28, 2020)

New traps per month, 2020
Month	Total	SMTP	SSH	POP3	Other
January	5085	171	4914	0	0
February	8941	150	8786	5	0
March	1363	258	1103	2	0
April	596	139	456	1	0
May	1406	108	1298	0	0
June	649	133	516	0	0
July	2405	98	2306	1	0
August	134	123	11	0	0
September	-	-	-	-	-
October	591	185	403	3	0
November	2843	1318	1525	0	0
December	1571	169	1402	0	0

Again for 2020 we have complete data on the of number of hosts in our spamd-greytrap, which in turn gives us this diagram of the year:

The data that went into producing the graph is available as 2020-traplistcounts.txt.

In 2021, still mostly a lockdown year, RFC7505 Means Yes, Your Domain Can Refuse to Handle Mail. Please Leave Us a TXT If You Do. (also here) (February 22, 2021) indicates a small but potentially significant change in mail server configuration. It has been a while since I last saw anything heading for that .se domain.

New traps per month, 2021
Month	Total	SMTP	SSH	POP3	Other
January	179	129	49	1	0
February	172	97	75	0	0
March	112	95	17	0	0
April	150	88	62	0	0
May	1360	90	1270	0	0
June	307	41	266	0	0
July	68	58	8	2	0
August	144	61	82	1	0
September	-	-	-	-	-
October	1035	160	875	0	0
November	166	94	72	0	0
December	304	192	112	0	0

The 2021 data of hosts in our spamd-greytrap produces this graph for the year:

The data that went into producing the graph is available as 2021-traplistcounts.txt.

By 2022, we were back out of lockdowns and I produced several relevant articles -- Spammers in the Public Cloud, Protected by SPF; Intensified Password Groping Still Ongoing; Spamware Hawked to Spamtraps (also here) (April 3, 2022) showed that our imaginary friends or at least a significant subset are indeed in common spamto: lists out there.

The Things Spammers Believe - A Tale of 300,000 Imaginary Friends (also here) (September 7, 2022) -- in which I had somehow not gotten around to celebrating the day when the number of spamtraps went past the number of inhabitants of my home town of Bergen, Norway and decided that a nice round number would serve just as well.

Harvesting the Noise While it's Fresh, Revisited (also here) (December 9, 2022) -- I realized that spammers with freshly generated spamto addresses may try more variants after the first one that gets them trapped, so I turned to some further digging into logs for new data. The numbers swelled slightly as a result.

Can Your Spam-eater Manage to Catch Seventy-one Percent Like This Other Service? (also here) (December 23, 2022) -- yet another piece to explain what greylisting and greytrapping is good for and why it is good for you.

The Despicable, No Good, Blackmail Campaign Targeting ... Imaginary Friends? (also here) (December 25, 2022) -- the first "they're sending wankstortion mail to my imaginary friends" article had not gotten much attention so I tried again.

New traps per month, 2022
Month	Total	SMTP	SSH	POP3	Other
January	143	129	14	0	0
February	333	79	253	0	16)
March	915	179	736	0	0
April	20451	91	20360	0	0
May	254	139	114	1	0
June	3898	54	3844	0	0
July	700	86	611	3	0
August	979	514	461	4	0
September	-	-	-	-	-
October	2111	597	1514	0	0
November	470	73	396	1	0
December	2030	1714	303	13	0

---

⁶⁾ fatfinger (see the data)

---

The 2022 data of hosts in our spamd-greytrap produces this graph for the year:

The data that went into producing the graph is available as 2022-traplistcounts.txt.

In 2023, we kept adding spamtraps as they came in and generating data, but no mail-themed articles at all.

New traps per month, 2023
Month	Total	SMTP	SSH	POP3	Other
January	642	175	465	2	0
February	429	301	128	0	0
March	8838	5296	3542	0	0
April	1557	1243	314	0	0
May	104	39	65	0	0
June	2273	2234	38	1	0
July	182	76	106	0	0
August	2436	2285	151	0	0
September	-	-	-	-	-
October	4008	3752	256	0	0
November	1912	96	1813	0	37)
December	1165	52	1113	0	0

---

⁷⁾ HTTP (see the data)

---

The 2023 data of hosts in our spamd-greytrap produces this graph for the year:

The data that went into producing the graph is available as 2023-traplistcounts.txt.

The year 2024 saw little innovation and no new episodes I found a reason to write about. However, that year saw the launch of Michael Lucas' much anticpiated Run Your Own Mail Server, and events somewhat related to that had me write A Simpler Life: Trapping Spambots Based on Target Domain Only (also here) (January 24, 2024) and its followup Three Minimalist spamd Configurations for Your Spam Fighting Needs (With Bonus Points at the End) (also here) (January 25, 2024).

If you have been reading carefully up to this point, you may have noticed what I only noticed myself when I started massaging my spamtraps added data into tables: That during the logged years 2017 through 2023, no new spamtraps were added during the month of September.

As time went by I had noticed that there were periods of up to several weeks when no new spamtrap candidates appeared, but it did not occur to me that every year up to that point, that period had actually been the entire month of September. It is possible or even likely that the change to a more aggressive method of searching for candidates in the logs is what filled up September from this year on.

During late November of 2024, I decided that the time had come to ditch the quasi-empirism of passively collecting the actual to: addresses and start making an effort to fill spammers' spamto: lists with as much junk as possible. So I started extracting local parts from the from: and hostname or host ID fields in my verbose spamd logs, splicing together a larger than ever number of fake @bsdly.net addresses for the spamtraps list. I also started digging back into archived spamd logs and extracting data from there. For obvious reasons, this means that from that point on, the overwhelming majority of the items tagged SMTP in the date added logs are of the synthetic kind. More of that later.

New traps per month, 2024
Month	Total	SMTP	SSH	POP3	Other
January	3122	92	3028	2	0
February	6442	202	6238	2	0
March	2150	198	1951	1	0
April	10028	5010	5018	0	0
May	633	413	219	1	0
June	680	72	608	0	0
July	177	151	25	1	0
August	561	433	125	3	0
September	3770	3675	95	0	0
October	10517	8631	1884	2	0
November	22899	18083	4815	1	0
December	167037	166605	428	4	0

The 2024 data of hosts in our spamd-greytrap produces this graph for the year:

The data that went into producing the graph is available as 2024-traplistcounts.txt.

We continued adding synthetic spamtraps from the from and host fields in both new and archived spamd logs into the new year 2025. This and a few related items are described in A Suitably Bizarre Start of the Year 2025 (also here) (January 1, 2025). In June I found I needed to clarify some things about the exported IP address lists, specifically that one should be considered a historical artifact only, and wrote Should I Stop Caring and Let IP Address Reputation Sort Them Out? (also here) (June 8, 2025).

Seeing that the number of spamtraps now had run into the millions, I decided to speed up the process of filling spamto lists with garbage a bit more, by generating a few thousand extra items from short snippets of /dev/random output, base64 encoded and stripped of certain characters that would possibly lead to spamdb not accepting the result as valid. An example one-liner would be (vary to taste)

for ((foo=4096;foo>=0;foo--)); do barone=`dd if=/dev/random bs=4 count=1 | base64 | tr -d '+=/\r'`; bartwo=`dd if=/dev/random bs=6 count=1 | base64 | tr -d '+=/\r'`; echo $barone.$bartwo@bsdly.net ; done | tee -a rawbar

The contents of the file rawbar would then be subject to the same checks (eliminating actually valid local addresses as well as the more commonly used of the RFC2142 mandated set) as any other before being fed to spamdb to swell the imaginary friends populations. I was sometimes surprised how many of the items output looked like they could conceivably have been part of something at least vaguely resembling human speech. Anyway, on to the data:

New traps per month, 2025
Month	Total	SMTP	SSH	POP3	Other
January	1400109	1399950	139	23	0
February	1261530	1260708	823	0	0
March	1142404	1141980	423	2	0
April	333442	333332	110	0	0
May	220072	218045	2027	0	0
June	180348	180271	75	2	0
July	242346	240771	1573	2	0
August	1020877	1020804	72	1	0
September	2025931	2025764	167	0	0
October	3249788	3249423	348	17	0
November	871177	871078	92	7	0
December	4056466	4056388	74	4	0

The 2025 data of hosts in our spamd-greytrap produces this graph:

The data that went into producing the graph is available as 2025-traplistcounts.txt.

At the end of the year, the total number of imaginary friends, or spamtraps, if you will, stood at 17008238.

The number swelled a bit in December, not only due to the continued intense traffic but mainly do to a few times during that month when I had the impulse to generate more varieties of synthetic entries.

Some came out of variations of the feeding off /dev/random I mentioned earlier, others came from using commands such as rot13 and rev on the things grep'ed out of the logs themselves. If you're that interested, I can share the shell oneliners with you, but they're not actually elegant so I will not bother to include them here.

New traps per month, 2026
Month	Total	SMTP	SSH	POP3	Other
January	5665771	5665271	466	34	0
February	643795	642962	829	4	0
March	2167109	2166892	179	38	0
April	1848919	1848809	85	25	0
May				0	0
May	1351938	1351801	123	14	0
June	1547849	1547597	248	4	0
July	1270088	1269407	677	4	0
August	2798004	2797908	93	3	0
September	1773798	1773466	331	1	0

The 2026 data of hosts in our spamd-greytrap produces this graph:

As I have mentioned earlier, there are a number of ways to find potential spamtrap material. In the early days, I simply extracted entries from the mail server logs with some very crude regular expression match using grep on the log files.

Later I set up to extract from the spamd greylist instead. That turned out to be a little shortsighted, since it would not then catch the attempted deliveries from a host that had already entered the blocklist. That thought only struck me again some years later, and in the 2022 piece Harvesting the Noise While it's Fresh, Revisited (also here) I run through how I amended the collection method a little.

The retrospective piece Eighteen Years of Greytrapping - Is the Weirdness Finally Paying Off? (also here) offers descriptions of a few other methods of creating spamtrap entries.

Then in the early days of January 2026, another episode involving a mail operator you will have heard about led me to write A Major Mail Provider Demonstrate They Likely Do Not Understand Mail At All (also here).

That episode also led me to realize that with a significant part of the traffic from at least that operator coming in over IPv6 or from a set of pre-cleared hosts such as the mail exchangers of the too big to block operators, there would be nothing logged by spamd anyway, so I set about collecting yet again candidate spamtraps from the real mailserver logs.

It turned out that by not looking at delivery attempts via IPv6, I had indeed been missing quite a significant number of potential imaginary friends.

As a result of the expanded scope of my noise harvesting, combined with some light massaging of the finds using tools such as rot13 and rev, the total number of added spamtraps for the month of January 2026 was

5665771

a total of five million, six hundred and sixty-five thousand, seven hundred and seventy-one added, so the total by end of January 2026 was more than twenty-two and a half million.

Where to Next, What Is Missing or Needed?

What happens next is not necessarily much different from what we have seen during all of those long years. Looking at the graphed data of number of trapped hosts, it is quite clear that the number of trapped hosts or IP addresses is on a declining trend, but with bursts or spikes when one or more campaigns are active and aimed at our domains. That general trend is possibly a consequence of the trend towards centralization of Internet services in general.

While I have not done any thorough analysis of the data, it appears that there is not a similar decline in delivery attempts, and some quasi-random sampling seems to indicate that it is fairly common that traffic from a single trapped IP address presents with a number of different hostnames or host IDs. This could be an indication that the senders sit in a cloud somewhere, or possibly are old-style compromised personal systems tucked away behind NAT.

That said, in my experience greylisting and greytrapping are useful techniques that work well within their limitations.

The limitation that irks me the most is that spamd is IPv4-only. While the migration to IPv6 has been slow, it is happening, and the portion of mail that is delivered over the modern protocol is increasing year by year. Around 2015 there was some work in the OpenBSD project on possibly extending spamd and supporting tools to support IPv6, but if I remember correctly the project was abandoned, at least partly because both parts of "rough consensus and working code" was not possible. Reaching consensus on how greylisting should work in the IPv6 world proved hard, to the point of turning out to being impossible.

I would personally hope that we can make progress towards IPv6 support at some point in the future, but until that happens, we can rest assured that a large part of the spammers have stayed on IPv4, and our tools work well to stop them in their tracks on the legacy protocol.

When I started working on this article, I had only a vague idea of how much I had actually written on the subject. I was a bit surprised at the number of pieces that had accumulated. I have included the list of links in the next, final section.

If you found this article useful, irritating, provoking, thought provoking, or simply would like to comment or contact me personally on the subject, please do.

---

The most recent exports of all lists generated here can be found in this directory. Before making any inguiries on removal from any of the lists, check all files in this directory for occurences or not of the IP address in question.

---

Previous spamd(8) Themed Articles and Field Notes

Hey, spammer! Here's a list for you! (also here) (July 9, 2007)

Spam is a solved problem (also here) (July 13, 2007)

The noise, we ignore it (tracked) (July 22, 2007)

Harvesting the noise while it's still fresh; SPF found potentially useful (also here) (July 25, 2007)

On the business end of a blacklist. Oh the hilarity. (tracked) (August 1, 2007)

We see your every move, spammer (tracked) (August 4, 2007)

A Lady in Distress; or Then Again, Maybe Not (tracked) (August 19, 2007)

Wanna help science? Study your greylists innards! (tracked) (September 8, 2007)

Always a pleasure to be wasting your time, guv (tracked) (September 29, 2007)

Of Course, It Had To Be A Webshield (tracked) (October 28, 2007)

I Must Be Living in a Parallel Universe, Then (also here) (November 25, 2007)

Fake Address Round Trip Time: 13 days (tracked) (May 21, 2008)

I challenge your response, backscatterer (tracked) (May 25, 2008)

Yes, we can! Make a difference, that is (tracked) (June 25, 2008)

Now that we have their addresses, do we name and shame? (tracked) (August 7, 2008)

Is one of your machines secretly a spambot? (tracked) (August 9, 2008)

“Name and Shame”, or socially responsible use of your log data (tracked) (September 22, 2008)

IETF failed to account for greylisting (also here) (October 20, 2008)

Oh yes, you signed up for this. You did. Honest. (also here) (March 21, 2009)

The Problem Isn't Email, It's Microsoft Exchange (also here) (February 27, 2011)

My First IPv6 Spam (also here) (June 8, 2011)

In The Name Of Sane Email: Setting Up OpenBSD's spamd(8) With Secondary MXes In Play - A Full Recipe (also here) (May 28, 2012)

Maintaining A Publicly Available Blacklist - Mechanisms And Principles (also here) (April 14, 2013)

Keep smiling, waste spammers' time (also here) (May 4, 2013)

The Hail Mary Cloud And The Lessons Learned (also here) (October 5, 2013)

Effective Spam and Malware Countermeasures - Network Noise Reduction Using Free Tools (also here) (February 2, 2014)

Password Gropers Take the Spamtrap Bait (also here) (August 12, 2014)

Does Your Email Provider Know What A "Joejob" Is? (also here) (April 23, 2016)

The Voicemail Scammers Never Got Past Our OpenBSD Greylisting (also here) (August 29, 2016)

Is SPF Simply Too Hard For Application Developers? (also here) (October 20, 2016)

So somebody is throwing HTML at your sshd. What to do? (also here) (December 22, 2016)

A New Year, a New Round of pop3 Gropers from China (also here) (January 9, 2017)

Twenty-plus years on, SMTP callbacks are still pointless and need to die (also here) (August 27, 2017)

A Life Lesson in Mishandling SMTP Sender Verification (also here) (February 17, 2018)

Badness, Enumerated by Robots (also here) (August 13, 2018)

Goodness, Enumerated by Robots. Or, Handling Those Who Do Not Play Well With Greylisting (also here) (November 4, 2018)

The Year 2019 in Review: This Was, Once Again, Weirder Than the Last One (also here) (December 28, 2019)

The 'sextortion' Scams: The Numbers Show That What We Have Is A Failure Of Education (also here) (February 28, 2020)

RFC7505 Means Yes, Your Domain Can Refuse to Handle Mail. Please Leave Us a TXT If You Do. (also here) (February 22, 2021)

Spammers in the Public Cloud, Protected by SPF; Intensified Password Groping Still Ongoing; Spamware Hawked to Spamtraps (also here) (April 3, 2022)

The Things Spammers Believe - A Tale of 300,000 Imaginary Friends (also here) (September 7, 2022)

Harvesting the Noise While it's Fresh, Revisited (also here) (December 9, 2022)

Can Your Spam-eater Manage to Catch Seventy-one Percent Like This Other Service? (also here) (December 23, 2022)

The Despicable, No Good, Blackmail Campaign Targeting ... Imaginary Friends? (also here) (December 25, 2022)

A Simpler Life: Trapping Spambots Based on Target Domain Only (also here) (January 24, 2024)

Three Minimalist spamd Configurations for Your Spam Fighting Needs (With Bonus Points at the End) (also here) (January 25, 2024)

A Suitably Bizarre Start of the Year 2025 (also here) (January 1, 2025)

Should I Stop Caring and Let IP Address Reputation Sort Them Out? (also here) (June 8, 2025)

Why 451 is Good for You - Greylisting Perspectives From the Early Noughties (December 28, 2025 , also here)

A Major Mail Provider Demonstrate They Likely Do Not Understand Mail At All (January 8, 2026, also here)

The Rest Is Trash (February 1, 2026, also here)

OpenSMTPD Is The Mail Server For The Future (May 15, 2026, also here)

---

Eighteen Years of Greytrapping - Is the Weirdness Finally Paying Off? is © 2025 Peter N. M. Hansteen (published 2025-08-10, updated several times including 2026-01-18)

---

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

At EuroBSDcon 2025, there will be a Network Management with the OpenBSD Packet Filter Toolset session, a full day tutorial starting at 2025-09-25 10:30 CET. You can register for the conference and tutorial by following the links from the conference Registration and Prices page.

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). We are hoping to have physical copies of the book available in time for the conference, and hopefully you will be able to find it in good book stores by then. The latest information I have is that physical copies should be ready to ship by the end of January 2026.

---

Chinese Hunting Chinese Over POP3 In Fjord Country

Yes, you read that right: There is a coordinated effort in progress to steal Chinese-sounding users' mail, targeting machines at the opposite end of the Eurasian landmass (and probably elsewhere).

More specifically, here at bsdly.net we've been seeing attempts at logging in to the pop3 mail retrieval service using usernames that sound distinctively like Chinese names, and the attempts originate almost exclusively from Chinese networks.

This table lists the user names and corresponding real life names attempted so far:

Name	Username
Chen Qiang	chenqiang
Fa Dum	fadum
Gao Dang	gaodang
Gao Di	gaodi
Gao Guan	gaoguan
Gao Hei	gaohei
Gao Hua	gaohua
Gao Liu	gaoliu
Gao Yang	gaoyang
Gao Zhang	gaozhang
He An	hean
He Biao	hebiao
He Bing	hebing
He Chang	hechuang
He Chao	hechao
He Chen	hechen
He Cheng	hecheng
He Chun	hechun
He Cong	hecong
He Da	heda
He Di	hedi
He Die	hedie
He Ding	heding
He Dong	hedong
He Duo	heduo
He Fa	hefa
He Ging	heqing
He Guo	heguo
He Han	hehan
He Hao	hehao
He Heng	heheng
He Hui	hehui
He Jia	hejia
He Jian	hejian
He Jiang	hejiang
He Jie	hejie
He Jin	hejin
He Juan	hejuan
He Kai	hekai
He Kan	hekan
He Kong	hekong
He La	hela
He Le	hele
He Leng	heleng
He Li	heli
He Lian	helian
He Lie	helie
He Mu	hemu
He Niang	heniang
He Quan	hequan
He Ran	heran
He Sha	hesha
He Shan	heshan
He Shi	heshi
He Si	hesi
He Song	hesong
He Xiao	hexiao
He Yao	heyao
He Yi	heyi
He Yin	heyin
He Yu	heyu
He Yun	heyun
He Zeng	hezeng
He Zeng	hezhan
He Zhang	hezhangxxxx
He Zhe	hezhe
He Zheng	hezheng
He Zhi	hezhi
He Zhong	hezhong
He Zhuang	hezhuang
Li An	lian
Li Biao	libiao
Li Bin	libin
Li Bo	libo
Li Cheng	licheng
Li Chi	lichi
Li Chong	lichong
Li Chuang	lichuang
Li Chun	lichun
Li Da	lida
Li Deng	lideng
Li Di	lidi
Li Die	lidie
Li Ding	liding
Li Dong	lidong
Li Duo	liduo
Li Fa	lifa
Li Fang	lifang
Li Fen	lifen
Li Feng	lifeng
Li Gang	ligang
Li Gao	ligao
Li Guan	liguan
Li Guang	liguang
Li Hai	lihai
Li Ka	lika
Li Kai	likai
Li La	lila
Li Le	lile
Li Lei	lilei
Li Lin	lilin
Li Ling	liling
Li Liu	liliu
Li Long	lilong
Li Man	liman
Li Mei	limei
Li Mu	limu
Li Neng	lineng
Li Niang	liniang
Li Peng	lipeng
Li Pian	lipian
Li Qian	liqian
Li Qu	liqu
Li Rang	lirang
Li Ren	liren
Li Ru	liru
Li Sha	lisha
Li Shi	lishi
Li Shuai	lishuai
Li Shun	lishun
Li Si	lisi
Li Song	lisong
Li Tao	litao
Li Teng	liteng
Li Tian	litian
Li Ting	liting
Li Wang	liwang
Li Wei	liwei
Li Wen	liwen
Li Xiang	lixiang
Li Xing	lixing
Li Xiu	lixiu
Li Ying	liying
Li You	liyou
Li Ze	lize
Li Zeng	lizeng
Li Zheng	lizheng
Li Zhong	lizhong
Li Zhu	lizhu
Li Zhuang	lizhuang
Li Zhuo	lizhuo
Liang Min	liangmin
Liang Ming	liangming
Liang Qiang	liangqiang
Liang Rui	liangrui
Lin Chen	linchen
Lin Cheng	lincheng
Lin He	linhe
Lin Hua	linhua
Lin Huang	linhuang
Lin Neng	linneng
Lin Pian	linpian
Lin Qu	linqu
Lin Ru	linru
Lin Zhang	linzhang
Liu Bin	liubin
Liu Duo	liuduo
Liu Fang	liufang
Liu Han	liuhan
Liu Hao	liuhao
Liu Heng	liuheng
Liu Hong	liuhong
Liu Hui	liuhui
Liu Jia	liujia
Liu Jiang	liujiang
Liu Jiao	liujiao
Liu Ju	liuju
Liu Juan	liujuan
Liu Kai	liukai
Liu Kan	liukan
Liu Kang	liukang
Liu Ke	liuke
Liu Kong	liukong
Liu Lang	liulang
Liu Long	liulong
Liu Mu	liumu
Liu Nuo	liunuo
Liu Qin	liuqin
Liu Qing	liuqing
Liu Qiong	liuqiong
Liu Rong	liurong
Liu Sen	liusen
Liu Sha	liusha
Liu Shun	liushun
Liu Si	liusi
Liu Tian	liutian
Liu Wang	liuwang
Liu Wei	liuwei
Liu Xia	liuxia
Liu Xiu	liuxiu
Liu Yao	liuyao
Liu Yi	liuyi
Liu Ying	liuying
Liu Yu	liuyu
Liu Yuan	liuyuan
Liu Yun	liuyun
Liu Zhen	liuzhen
Liu Zheng	liuzheng
Liu Zhi	liuzhi
Liu Zun	liuzun
Lou Liu	luoliu
Lu Huang	lihuang
Luo Chang	luochuang
Luo Chen	luochen
Luo Cheng	luocheng
Luo Deng	luochi
Luo Deng	luodeng
Luo Di	luodi
Luo Dian	luodian
Luo Gao	luogao
Luo Guai	luoguai
Luo Hang	luohuang
Luo Hua	luohua
Luo Lie	luolie
Luo Neng	luoneng
Luo Pian	luopian
Luo Qi	luoqi
Luo Qin	luoqin
Luo Qing	luoqing
Luo Qu	luoqu
Luo Rong	luorong
Luo Ru	luoru
Luo Rui	luorui
Luo Shuang	luoshuang
Luo Ting	luoting
Luo Tong	luotong
Luo Wang	luowang
Luo Wei	luowei
Luo Yang	luoyang
Luo Ze	luoze
Song Chen	songchen
Song Cheng	songcheng
Song Chuang	songchuang
Song Da	songda
Song Deng	songdeng
Song Dian	songdian
Song Die	songdie
Song Fei	songfei
Song Fen	songfen
Song Gang	songgang
Song Gao	songgao
Song Guai	songguai
Song Guan	songguan
Song Guo	songguo
Song Hai	songhai
Song Han	songhan
Song Hang	songhang
Song He	songhe
Song Hei	songhei
Song Heng	songheng
Song Hu	songhu
Song Hua	songhua
Song Jia	songjia
Song Jiao	songjiao
Song Jie	songjie
Song Jin	songjin
Song Jing	songjing
Song Ka	songka
Song Kan	songkan
Song Kang	songkang
Song Kong	songkong
Song Lan	songlan
Song Le	songle
Song Lei	songlei
Song Lian	songlian
Song Liang	songliang
Song Liang	songliao
Song Liang	songliang
Song Liao	songliao
Song Lin	songlin
Song Liu	songliu
Song Meng	songmeng
Song Ming	songming
Song Mu	songmu
Song Nan	songnan
Song Neng	songneng
Song Ning	songning
Song Pian	songpian
Song Pin	songpin
Song Qi	songqi
Song Qiang	songqiang
Song Qing	songqing
Song Qiu	songqiu
Song Ran	songran
Song Rong	songrong
Song Rui	songrui
Song Sha	songsha
Song Shuai	songshuai
Song Shuang	songshuang
Song Song	songsong
Song Song Jun	songsongjun
Song Tao	songtao
Song Teng	songteng
Song Wang	songwang
Song Wei	songwei
Song Xi	songxi
Song Xia	songxia
Song Xiu	songxiu
Song Ya	songya
Song Yang	songyang
Song Yong	songyong
Song You	songyou
Song Yuan	songyuan
Song Yue	songyue
Song Yun	songyun
Song Zhe	songzhe
Song Zhen	songzhen
Song Zheng	songzheng
Song Zhuang	songzhuang
Tan Qian	tangqian
Tang Bing	tangbing
Tang Chi	tangchi
Tang Chong	tangchong
Tang Chuang	tangchuang
Tang Cong	tangcong
Tang Di	tangdi
Tang Dian	tangdian
Tang Duo	tangduo
Tang Fa	tangfa
Tang Fan	tangfan
Tang Fang	tangfang
Tang Fei	tangfei
Tang Fen	tangfen
Tang Feng	tangfeng
Tang Gang	tanggang
Tang Guai	tangguai
Tang Guan	tangguan
Tang Guang	tangguang
Tang Guo	tangguo
Tang Han	tanghan
Tang Hao	tanghao
Tang Hei	tanghei
Tang Heng	tangheng
Tang Hong	tanghong
Tang Hu	tanghu
Tang Hui	tanghui
Tang Jie	tangjie
Tang Jin	tangjin
Tang Jing	tangjing
Tang Ju	tangju
Tang Ka	tangka
Tang Kai	tangkai
Tang Kan	tangkan
Tang Kang	tangkang
Tang Ke	tangke
Tang Kong	tangkong
Tang La	tangla
Tang Lang	tanglang
Tang Le	tangle
Tang Leng	tangleng
Tang Li	tangli
Tang Lian	tanglian
Tang Lie	tanglie
Tang Lin	tanglin
Tang Ling	tangling
Tang Liu	tangliu
Tang Long	tanglong
Tang Mei	tangmei
Tang Mo	tangmo
Tang Mu	tangmu
Tang Neng	tangneng
Tang Niang	tangniang
Tang Nuo	tangnuo
Tang Peng	tangpeng
Tang Pian	tangpian
Tang Ping	tangping
Tang Qian	tangqian
Tang Qin	tangqin
Tang Qu	tangqu
Tang Quan	tangquan
Tang Quing	tangqing
Tang Rang	tangrang
Tang Ren	tangren
Tang Ru	tangru
Tang Ruan	tangruan
Tang Rui	tangrui
Tang Sen	tangsen
Tang Sha	tangsha
Tang Shan	tangshan
Tang Shi	tangshi
Tang Shun	tangshun
Tang Song	tangsong
Tang Tang Jun	tangtangjun
Tang Tao	tangtao
Tang Tian	tangtian
Tang Tian	tangyan
Tang Wei	tangwei
Tang Xi	tangxi
Tang Xia	tangxia
Tang Xing	tangxing
Tang Xiong	tangxiong
Tang Yan	tangyan
Tang Yang	tangyang
Tang Yao	tangyao
Tang Yi	tangyi
Tang Ying	tangying
Tang Yong	tangyong
Tang You	tangyou
Tang Yue	tangyue
Tang Yun	tangyun
Tang Ze	tangze
Tang Zeng	tangzeng
Tang Zhang	tangzhang
Tang Zhe	tangzhe
Tang Zhen	tangzhen
Tang Zun	tangzun
Xie An	xiean
Xie Bin	xiebin
Xie Bo	xiebo
Xie Chao	xiechao
Xie Cong	xiecong
Xie Da	xieda
Xie Di	xiedi
Xie Dian	xiedian
Xie Die	xiedie
Xie Ding	xieding
Xie Dong	xiedong
Xie Duo	xieduo
Xie Fang	xiefang
Xie Fei	xiefei
Xie Feng	xiefeng
Xie Gang	xiegang
Xie Gao	xiegao
Xie Guai	xieguai
Xie Guan	xieguan
Xie Hai	xiehai
Xie Hang	xiehang
Xie Heng	xieheng
Xie Heng	xieneng
Xie Heng	xieheng
Xie Heng	xieneng
Xie Hong	xiehong
Xie Hu	xiehu
Xie Hui	xiehui
Xie Jia	xiejia
Xie Jian	xiejian
Xie Jiang	xiejiang
Xie Jiao	xiejiao
Xie Jie	xiejie
Xie Jing	xiejing
Xie Ju	xieju
Xie Kai	xiekai
Xie La	xiela
Xie Leng	xieleng
Xie Liang	xieliang
Xie Lie	xielie
Xie Lin	xielin
Xie Ling	xieling
Xie Long	xielong
Xie Man	xieman
Xie Meng	xiemeng
Xie Min	xiemin
Xie Ming	xieming
Xie Na	xiena
Xie Niang	xieniang
Xie Peng	xiepeng
Xie Pian	xiepian
Xie Pin	xiepin
Xie Qi	xieqi
Xie Qing	xieqing
Xie Qiong	xieqiong
Xie Qiu	xieqiu
Xie Qu	xiequ
Xie Quan	xiequan
Xie Ran	xieran
Xie Ruan	xieruan
Xie Rui	xierui
Xie Sha	xiesha
Xie Shuang	xieshuang
Xie Si	xiesi
Xie Tao	xietao
Xie Ting	xieting
Xie Tong	xietong
Xie Wei	xiewei
Xie Wen	xiewen
Xie Xi	xiexi
Xie Xiang	xiexiang
Xie Xin	xiexin
Xie Xing	xiexing
Xie Xiu	xiexiu
Xie Ya	xieya
Xie Yi	xieyi
Xie Yin	xieyin
Xie Ying	xieying
Xie Yong	xieyong
Xie Yu	xieyu
Xie Yue	xieyue
Xie Zeng	xiezeng
Xie Zhan	xiezhan
Xie Zhang	xiezhang
Xie Zhe	xiezhe
Xie Zhuo	xiezhuo
Zheng Nan	zhengnan

That list of some 493 names is up to date as of this writing, 2016-08-23 early evening CEST. A few more turn up with the bursts of activity we have seen every day since June 19th, 2016.

A possibly more up to date list is available here. That's a .csv file, if that sounds unfamiliar, think of it as a platform neutral text representation (to wit, "Comma Separated Values") of a spreadsheet or database -- take a peek with Notepad.exe or similar if you're not sure. I'll be updating that second list along with other related data at quasi-random intervals as time allows and as long as interesting entries keep turning up in my logs.

If your name or username is on either of those lists, you would be well advised to change your passwords right now and to check breach notification sites such as Troy Hunt's haveibeenpwned.com or breachalarm.com for clues to where your accounts could have been compromised.

That's your scoop for now. If you're interested in some more background and data, keep reading.

If you are a regular or returning reader of this column, you are most likely aware that I am a Unix sysadmin. In addition to operating and maintaining variuos systems in my employers' care, I run a small set of servers of my own that run a few Internet-facing services for myself and a small circle of friends and family.

For the most part those systems are roundly ignored by the world at large, but when they are not, funny, bizarre or interesting things happen. And mundane activities like these sometimes have interesting byproducts. When you run a mail service, you are bound to find a way to handle the spam people will try to send, and about ten years ago I started publishing a blacklist of known spamming hosts, generated from attempts to deliver mail to a slowly expanding list of known bad, invalid, never to be deliverable addresses in the domains we handle mail for.

After a while, I discovered that the list of spamtrap addresses (once again, invalid and destined never to be deliverable, ever) had been hilariously repurposed: The local parts (the string before the @ or 'at sign') started turning up as usernames in failed attempts to log on to our pop3 mail retrieval service. That was enough fun to watch that I wrote that article, and for reasons known only to the operators of the machines at the other end, those attempts have never stopped entirely.

These attempts to log in as our imaginary friends is a strong contender for the most bizarre and useless activity ever, but when those attempts were no longer news, there was nothing to write about. The spamtrap login attempts make up sort of a background noise in the authentication logs, and whenever there is an attempt to log in as a valid user from somewhere that user is clearly not, the result is usually that an entire network (whatever I could figure out from whois output) would be blocked from any communication with our site for 24 hours.

There are of course also attempts to log in as postmaster, webmaster and other IDs, some RFC mandated, that most sites including this one would handle as aliases to make up the rest of the background noise.

Then recently, something new happened. The first burst looked like this in my logs (times given in local timezone, CEST at the time):

Jun 19 06:14:58 skapet spop3d[37601]: authentication failed: no such user: lilei - 59.54.197.34
Jun 19 06:15:01 skapet spop3d[46539]: authentication failed: no such user: lilei - 59.54.197.34
Jun 19 06:15:03 skapet spop3d[8180]: authentication failed: no such user: lilei - 59.54.197.34

-- and so on, for a total of 78 attempts to log in as the non-existing user lilei, in the space of about five minutes. A little later, a similar burst of activity came for the user name lika:

Jun 19 14:11:30 skapet spop3d[68573]: authentication failed: no such user: lika - 182.87.253.48
Jun 19 14:12:22 skapet spop3d[22421]: authentication failed: no such user: lika - 182.87.253.28
Jun 19 14:12:26 skapet spop3d[7587]: authentication failed: no such user: lika - 182.87.253.28
Jun 19 14:12:30 skapet spop3d[16753]: authentication failed: no such user: lika - 182.87.253.28

and so on, for a total of 76 attempts. Over the next few days I noticed an uptick in failed pop3 access attempts that were not for valid users and did not match any entry on our spamtraps list. Still, those attempts were for users that do not exist, and would produce no useful result so I did not do anything much about them.

It was only during the early weeks of July that it struck me that the user name attempted here

Jul  8 12:19:08 skapet spop3d[54818]: authentication failed: no such user: lixing - 49.87.78.12
Jul  8 12:19:28 skapet spop3d[1987]: authentication failed: no such user: lixing - 49.87.78.12
Jul  8 12:19:37 skapet spop3d[70622]: authentication failed: no such user: lixing - 49.87.78.12
Jul  8 12:19:49 skapet spop3d[31208]: authentication failed: no such user: lixing - 49.87.78.12

(a total of 54 attempts for that user name) might actually be based on the name of a Chinese person. "Li Xing" sounded plausible enough as a possible real person. It's perhaps worth noting that at the time I had just finished reading the first two volumes of Cixin Liu's The Three Body Problem, so I was a bit more in tune than usual with what could be plausible Chinese names than I had been. (And yes, the books are very much to my taste and I have the yet unpublished translation of the third volume on pre-order.)

Unsurprisingly, a quick whois lookup revealed that the machines that tried reading the hypothetical person Li Xing's mail all had IP addresses that belonged to Chinese networks.

Once I realized I might be on to a new pattern, I went back over a few days' worth of failed pop3 login attempts and found more than a handful of usernames that looked like they could be based on Chinese names. Checking the whois data for the IP addresses in those attempts, all turned out to be from Chinese networks.

That was in itself an interesting realization, but a small, random sample does not make for proof. In order to establish an actual data set, it was back to collecting data and analysing the content.

First, collect all log data on failed pop3 attempts for a long enough period that we have a reasonable baseline and can distinguish between the background noise and new, exciting developements.

The file bigauthlog is that collection of data. Digging through my archives going back in time, I stopped at January 16, 2016 for no other reason than this would be roughly six months' worth of data, probably enough to give a reasonable baseline and to spot anomalies.

If you've read the previous columns, you will be familiar with the scripts that produce various text and CSV reports from log data input: A text report of user names by number of access attempts, a CSV dump of the same, with first and last spotted, a text report of hosts attempting access, sorted by number of attempts, a CSV dump of the same, with first and last seen dates as for the user names.

But what I wanted to see was where the login attempts were coming from for which usernames, so I started extracting the unique host to username mappings. For each entry in this CSV file, there is a host and a user name it has tried at least once (if you import that somewhere, make sure you mark the Username column as text -- LibreOffice Calc at least becomes confused when trying to parse some of those strings). The data also records whether that particular username was part of the spamtrap database at the time. If you want to do that particular check on your own greytrapping database, any matching output from

$ doas spamdb | grep -i username@

on your greytrapper box will mean it is in your list. And then finally for each entry there is the expected extract from available whois info: network address range, the network name and the country.

The most useful thing to do with that little database is to play with sorting on various fields and field combinations. If you sort on the "In spamtraps" field, the supposed Chinese names turn up with "No"s, along with a few more random-seeming combinations.

While I was building the data set I decided to add those new usernames with @bsdly.net appended to the spamtraps, and this is what finally pushed the number of spamtraps past the 30,000 mark.

Just browsing the data or perhaps sorting by IP address will show you that the pop3 gropers are spread across a large number of networks in a number of countries and territories with numbers roughly in proportion to the size of that country or territory's economy. Some, such as a particular Mexican ISP and cable TV operator stand out as being slightly over-represented, and as expected networks in the US and China stand for a large number of the total.

If you sort on the In spamtraps field, you will see that a large number of the entries that were not in the spamtraps are the ones identified as Chinese personal names, but not all. Some of the No entries are the RFC mandated mailboxes, some are aliases that are in use here for other reasons, and finally more than a handful that would fit the general description of the rest of the spamtraps: Strings superficially resembling personal names or simply random strings. These may be parts of the potential spamtraps I missed while fishing  spamtrap candidates out of logfiles some time over the decade of weirdness that has gone into maintaining the spamtraps list.

But if you sort the data primarily on the fields Name, Country, and if you like IP address and User name, you will see that as anticipated the attempts on Chinese-sounding user names come exclusively from Chinese networks, except only the "Fa Dum" (fadum) user, which appears to have been attempted only twice (on June 6th) from an IP address registered in the USA and may very well be a misclassification on my part. That particular sorting, with duplicates removed, is the origin of the list of names and usernames given earlier in this article and this CSV file.

Now that we have established that the attempts at Chinese user names come exclusively from Chinese networks, the next questions become: Who are the cyber criminals behind this activity, and what are their motivations? And why are they bothering with hosts in faraway Europe to begin with?

For the first question, it is hard to tell from this perch, but whoever runs those attempts apparently have the run of large swathes of network real estate and seem to not take any special care not to be detected, other than of course distributing the attempts widely across the network ranges and coming in only in short bursts.

So are those attempts by, let us say the public sector, to steal political dissidents' email? Or perhaps, still with a public sector slant, simply hunting for any and all overseas assets belonging to Chinese nationals? Or are we simply seeing the activities of Chinese private sector cyber criminals who are trying out likely user names wherever they can find a service that listens?

Any of all of these things could be true, but in any case it's not unlikely that what we are seeing somebody trying to find new places where username and password combinations from a recent breach might work. After all, username and password combinations that have been verified to work somewhere are likely worth more on the market than the unverified ones.

Looking at the log entries, there are sequences there that could plausibly have been produced by humans typing at keyboards. Imagine if you please vast, badly lit and insufficiently ventilated Asian cyber-sweatshops, but I would not be too surprised to find that this is actually a highly automated operation, with timing tuned to avoid detection.

Security professionals have been recommending that people stop using the pop3 protocol since as long as I care to remember, but typing "pop3" into shodan.io still produces a whopping 684,291 results, meaning that the pop3 service is nowhere near as extinct as some would have preferred.

The large number of possible targets is a likely explanation for the burstiness of the activity we are seeing: with that many hosts to cover, the groping hosts will need to set up some sort of rotation, and in addition there is the need to stay below some volume of traffic per host in order to avoid detection. This means that what any one site sees is only a very small part of the total activity. The pop3 hunt for Chinese users is most likely not exclusive to the fjord country.

If you run a pop3 service, please do yourself a favor and check your setup for any weaknesses including any not yet applied updates, as you were about to do anyway. Once you've done that, take some moments to browse your logs for strange looking login attempts.

If you find something similar to what I've reported here, I would like to hear from you. Please note that at least one of the pop3 deaemons out there by default does not report the username for failed authentication attempts but notes that the username was unknown instead. Anyway, your war stories will be appreciated in email or comments.

If your name or username appears in the table at the start of this article or in this CSV file, please start checking for unusual activity involving your accounts and start changing passwords right away. Ask your service providers if they offer more secure alternatives, and if they do, consider using these alternatives. And as I mentioned earlier, do check breach notification sites such as haveibeenpwned.com or breachalarm.com for clues to help find out whether your data could be at risk in any of the services you do use. And of course, feedback in comments or email is welcome.

And finally, if you have information on one or more breaches that may have been the source of this list of likely Chinese user names, I'd like to hear from you too.

Good night and good luck.

---

Update 2016-10-15: The attempts at logging in with Chinese-sounding user names from hosts in Chinese networks became incrementally less frequent over time, and seem to have stopped entirely in early October 2016.

The final entry is this one, from October 6:

Oct  6 18:11:23 skapet spop3d[97769]: authentication failed: no such user: maxiang - 114.99.9.152

That is, an attempt from the IP address range assigned to the Chinanet Anhui province network, for the user name maxiang which may very well map to Ma Xiang (or Xiang Ma) as a person's name.

During the months they were active, the robots or sweatshops in the Chinese networks tried a total of 957 distinct user names, from 3794 distinct hosts for a total of 3998 host-username combinations.

Although the number of failed pop3 attempts have now fallen to almost none (bar a treesome of persistent miscreants in the Quasi Networks, Seychelles IP address range), I will make an effort to publish updates to the data at not too infrequent intervals. You are of course free to use the data in your own analyses, as long as reasonable credit is given for the data collection. If you're unsure what that means, please contact me directly (the address in the whois information works).

Update 2016-12-07: Even though the campaign that prompted me to write this article has ended or moved its attention elsewhere, I do update the data occasionally. Returning readers may be happy to hear about a slight enhancement in presentation of the data: Startiing with today's edition, I've added an 'Attempts'  column to the main .csv file, denoting the number of attempts for each host-username pair.

Update 2017-02-08: Another round of attempts at usernames that are likely Chinese user names started on February 8th, 2017.

The first few hours brought the following user names, with the likely corresponding real life name in the second column:

Name	Username
Luo Chun	luochun
Luo Fa	luofa
Luo Feng	luofeng
Luo Hai	luohai

These names have been added to the full data as well as the 2017-only portion. The log file (2016 and 2017 version or 2017-only data) contains the entries starting at Feb  8 15:26:45 (times are CET local time). It will be interesting to see how long this cycle lasts. Look for updates to the data at irregular but hopefully frequent intervals.

If you are seeing similar activity, I would like to hear from you, in comments or (these most recent attempts all originate in the 49.64.0.0/11 network (range 49.64.0.0 - 49.95.255.255, also known as  CHINANET-JS or the CHINANET jiangsu province network). The previous cycle involved several distinct Chinese networks, and as we all know, stretched over several months of low intensity activity.

---

I would like to thank Tore Nordstrand and Øystein Alsaker for valuable input on various aspects of this article.
The data referenced in this article will likely be updated on a roughly daily basis while the Chinese episode lasts. You can fetch them from the links in the article or from this directory, which also contains some trivial data extraction and data massaging scripts I use. If you find any errors or have any concerns, please let me know.