© 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
!!!!!!!!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-fice 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.
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).
Posts
