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 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 towh 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

and rawbar would then be subject to the same checks (eliminating actually valid local addresses as well as the more commonly used of the RFC21 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	245893	245891	2	0	0

The 2025 data up to the publication date of hosts in our spamd-greytrap produces this graph:

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

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

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 (tracked) (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)

---

Eighteen Years of Greytrapping - Is the Weirdness Finally Paying Off? is © 2025 Peter N. M. Hansteen (published 2025-08-10)

---

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.

---

Elvis is alive! How 'AI' stunts modern mythmaking

© 2025 Peter N. M. Hansteen

A chance followup to an old geek joke reveals how AI creates myths based on severely limited historical inputs

Sometimes LinkedIn discussions run much like informal office banter. Earlier this week, Niall Murphy posted there, saying

Best joke hostnames? I'll go first:
"switchen" - network equipment close to the fridge
"madwoman" - storage server somewhere up high (guess how high)
"wutheringbytes" - storage server in rural surroundings

This had me respond with

Never forget that it is required for any network with Solaris boxes to have one host called elvis

This comes from a fairly widely known and respected part of geek culture, based on the Solaris operating system's implementation of the ping(8) command.

---

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

---

If you're a Unix person, you will get the joke immediately after following the link to the ping(8) manual page and reading the first three lines of the DESCRIPTION part.

The cultural background is a reference to Elvis Presley, the "King of Rock'n'Roll", who passed away in August of 1977. Pretty much immediately after the sad news arrived via ordinary channels, speculations started turning up that The King was not actually deceased.

There have been quite a few versions of those rumors in circulation, and if some of those were to be believed, our man had actually arranged a disappearance in order to join some top secret undercover assignment for one or more of the federal three letter agencies of the United States govenment.

Be that as it may, fast forward a few years, and by the time I entered the ranks of Solaris admins, it had become something of a standing joke to put new hires in front of a terminal or simply an Xterm open on a Solaris box and tell them to enter ping elvis and press Enter.

The interaction would then run like this:

$ ping elvis
elvis is alive


at this point everybody would have a laugh, and work would go on. Until the next rookie turned up.

That was the joke, repeated almost ad nauseam at all Solaris sites I have been to.

So I was a bit surprised by Niall's followup

Peter Hansteen glad to see Gemini's got it's finger on the pulse:
"Bohunt School:
The context of the phrase "Elvis Solaris" comes from a Facebook post from Bohunt School, indicating the school used the dogs to help students with their well-being. "

My immediate reaction was along the lines of that's bulls**t, phrased as

Whatever they fed that one, I don't think I want to know.

ping(1)!

A screenshot of the entire sequence is preserved here.

-- and my impulse here was that this was yet another example of AI hallucination, courtesy of the Gemini assistant tool. After all, what other link between Elvis Presley, King of Rock'n'Roll and the Solaris operating system could conceivably exist? So I just dismissed the thought and went on with my day.

But the next morning I noticed I was still slightly irritated by the whole thing, so I decided to investigate again, using the clues Niall had provided.

Searching with the obvious keywords, it turned up that indeed, a series of Facebook posts existed that showed that in connection with Bohunt School, an outfit calling itself Solaris Healthcare had indeed been involved in a number of events using the name Elvis in the event title, apparently involving one or more Elvis impersonators.

So the reference was real after all.

The thing was not completely made up, but pointing to those Facebook posts about the Elvis themed events as the original context shows very clearly what the language model was trained on. They included social media posts, but apparently did not manage to suck in references to a fairly widely know part of geek or hacker culture.

To my mind at least, this shows that even the latest fad in Artificial intelligence (AI)has been unable to evade one basic truth about information processing systems:

The quality and usefulness of the output from any information system depends critically on the inputs provided for the system to process.

Or as some less kind commentators have uttered, Garbage in, garbage out (GIGO for short).

When the hypemasters of the large language models forget this simple truth about their systems, we all end up poorer for it. The tool acts as if it has absorbed all knowable truth, and presents it with all the confidence of a veteran mansplainer. Whatever was not in the training data set simply falls by the wayside.

If in this way modern myths and folklore stripped away and deleted, only what the robot trainers could be bothered included, and as a consequence the scope of what will form our future myths and folklore culture becomes narrowed and stunted.

This all echoes the sentiments that I found in a fediverse post that I lost the original reference for, but which I included in my my pinned post,

I just saw a post that referred to ChatGPT as "Mansplaining as a service", and it is so wonderfully correct - instant generation of superficially plausible yet totally fabricated nonsense presented with unflagging confidence, regardless of topic, without concern, regard, or even awareness of the expertise of its audience :D #chatgpt #mansplaining #GenerativeAiIsGoingGreat

Take "ChatGPT" there as a stand-in for "any large language model system". In the current iteration of what popular culture considers Artificial intelligence, much of the hype we have heard can be condensed to

"but this time around, it is laced with our special large language model magic."

The sceptics among us might be justified in thinking

"actually, this time around its GIGO+M (Garbage in, Garbage out, plus magic)".

I am an old man. I regularly yell at clouds.

Good night and good luck! I welcome your comments.

Bonus note: Niall told me in a message, about the "is alive" reference, he was "wondering if it was sourced anywhere and turned to my favourite search engine to see. And that was the Gemini result placed at the top, which I thought was so beautifully wrong/weird I should share it with you..."

---

Update 2025-08-07: My colleague Eirik Sangolt decided to put OpenAI GPT-4.1 to the task of explaining.

Here is what happened:

Eirik: Explain the following Tweet: "Never forget that it is required for any network with Solaris boxes to have one host called elvis."

OpenAI:
The Tweet "Never forget that it is required for any network with Solaris boxes to have one host called elvis." is a reference to a long-standing joke in the Unix and Solaris system administration community.

Explanation:

• Solaris is a Unix operating system originally developed by Sun Microsystems.
• In Solaris, there is a command called ping used to test network connectivity.
• If you run the command ping elvis on a Solaris system, the system responds with:
  elvis is alive
• This is a playful Easter egg built into Solaris. The system is pretending that "elvis" is a host on the network, and the phrase "elvis is alive" is a joke referencing the popular culture myth that Elvis Presley is still alive.

So, the Tweet is a joke:
It suggests that every network with Solaris machines should have a host named "elvis" so that when someone runs ping elvis, they get the amusing response. In reality, it's not a technical requirement-just a bit of fun for system administrators.

If you want more details or examples of other Unix jokes or Easter eggs, let me know!

This response is Al generated and is based only on parts of the available information. Do not use it as a basis for important decisions.

Screenshot preserved here.

I think perhaps the answer provided here could be based on fairly low rated stackoverflow answers.

---

Elvis is alive! How 'AI' stunts modern mythmaking is © 2025 Peter N. M. Hansteen (published 2025-08-06)

---

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.

---

Those Titles the AI Bot Thought I Had Written

© 2024 Peter N. M. Hansteen (2024-12-06)

Beware of robots generating your references. They could very well take it upon themselves to lie on your behalf. Testing in 2023, I observed a whopping 25% truth in the result. What is the truth rating in 2024?

Note: This is a field note that was originally intended as a fediverse (mastodon) post, but the text would have overflowed into a thread and would then have become quite cumbersome.

Back in the early days of generative Artificial Intelligence revolution (read: late 2023) I had heard enough of the hype that I did a few minimal experiments (see my earilier notes ChatGPT opines on IPv6 procastination, waxes lyrical over OpenBSD (also prettified, tracked) and I asked ChatGPT to write a pf.conf to spec, 2023-06-07 version (also prettified, tracked)) that had me conclude that for my own purposes at least, the technology as it appeared at the time was unlikely to improve productivity for myself or any of my immediate colleagues.

The TL;DR would be that since the models will only become somewhat useful if they are trained on a sufficient volume of material within the topic of interest, clearly a lot of work needed to be done. Basically, the gaps in the training data seemed to fit essentially most of the field I deal with professionally, beyond of course a few trivial generalities. And those were cracks that could only be papered over at the cost of pulping several good-sized forests.

---

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

---

Not easily discouraged, I thought maybe, it just might be, that the data the language model trainers had sucked in from public sources on the Internet would contain enough factual information that the system would be able to cough up a reasonable bibliography of what I had written.

So I opened another session with the same robot and typed

---

what are the most read articles by Peter N. M. Hansteen?

---

After a brief pause, the cursor started moving and presented its result:

---

As an AI language model, I don't have real-time access to up-to-date information or specific statistics on article readership. Additionally, my training only goes up until September 2021, so I may not be aware of the most recent articles published by Peter N. M. Hansteen. However, I can provide you with some notable articles that Peter N. M. Hansteen has written up until my knowledge cutoff date.

Peter N. M. Hansteen is a well-known author and has written extensively on the topic of networking and computer security, particularly focused on OpenBSD and firewalls. Some of his notable articles include:

"The Book of PF: A No-Nonsense Guide to the OpenBSD Firewall" - This is a comprehensive guide that provides practical information on setting up and configuring firewalls using OpenBSD's PF (Packet Filter) system. It covers topics such as filtering network traffic, NAT (Network Address Translation), and quality of service (QoS).

"Building Firewalls with OpenBSD and PF" - This article discusses the concepts and techniques involved in building firewalls using OpenBSD and its PF system. It provides practical examples and guidance on firewall design and implementation.

"Securing the Edge: A Practical Introduction to OpenBSD Packet Filtering" - This article focuses on the fundamentals of packet filtering using OpenBSD's PF system. It covers topics such as rule syntax, filtering criteria, and advanced filtering techniques.

"So You Want to Be a Firewall Wizard? Part 1" and "Part 2" - These two-part articles provide an introduction to firewall concepts and techniques, with a focus on OpenBSD and PF. They cover topics such as rule sets, network address translation, and handling complex firewall configurations.

Please note that the popularity of articles can vary over time, and it's always best to refer to the author's official website, blog, or other reliable sources for the most up-to-date information on their publications and readership.

---

(Preserved as text, cut and pasted from the website, here)

My initial reaction when I saw the result was a sound you would associate with something quite unpleasant happening.

I'll take one paragraph at the time.

Though it was probably intended as a disclaimer, the claims in the first paragraph there are, as we shall see, only 25% true, if even that.

The second paragraph has a description of me that is on par for what would turn up in a not terribly specific search using your favorite Internet search engine.

Just how well known an author and what consitutes extensive writing is open for discussion, but at least the paragraph as a whole is not counter-factual.

I did write The Book of PF. The third edition of book would have been available via that link and a few others at the September 2021 cutoff date, and the description is a valid, if somewhat short of exhaustive, description of the book when it comes to subjects covered.

However, the three titles that follow were not written by me.

I think I have read articles matching those titles at some point, but the actual authors of those pieces would not be terribly pleased to have them attributed to somebody else. I would assume their publishers would like a word there too.

I have mentioned this session a few times to colleagues and friends over refreshments, but I have not really give it much thought since.

But the chatter about how the AI bot herders are heroically fighting their charges' tendency to hallucinate seems to never come to an end.

So my question to you is: Has the situation actually improved since then?

If you have any useful experience to share or other input on the subject, please follow up with a comment in the thread where you found the reference to this note.

A reasonable followup question would be,

Are the efforts that go into (what is currently labeled as) Artificial Intelligence starting to pay off?

followed by

or are we for now better served by having the abbreviation "AI" (perhaps more reasonably) expand to "Artificial Inanity"?

Come to think of it, unless the various bots that scrape the net actually obey my robots.txt directives, publishing even this text here will lead to further confusion over who actually wrote those titles. This is bound to turn up in the AI slop presented to some poor soul looking for valid information.

Again, if you have any useful insigths or experiences you want to share on the subject, please follow up with a comment where you found the link to this piece, or post to this fediverse thread (raw link https://mastodon.social/@pitrh/113612679976829404).

I look forward to reading your comments.

---

Those Titles the AI Bot Thought I Had Written is © 2024 Peter N. M. Hansteen (published 2024-12-06)

---

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

---

Yes, The Book of PF, 4th Edition Is Coming Soon

© 2025 Peter N. M. Hansteen

Long rumored and eagerly anticipated by some, the fourth edition of The Book of PF is now available for preorder

This week it was finally time to announce, to the fediverse and to mailing lists, that there is a new edition of The Book of PF in the works, and preordering is now enabled.

---

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

---

A few questions immediately pop into readers' minds on hearing this news. The ones I get most often are,

Why now? What took you so long?

which quite frequently combines with

What changed? Are previous editions now useless?

I'll address both after repeating what I said in the email announcements:

The fourth edition was written to bring the text into sync with the realities of the modern Internet, seen from the perspective of someone working with OpenBSD 7.8 or FreeBSD 14-STABLE.

The structure and chapter titles will be recognizable to readers of the previous edition, with the content updated to reflect the realities of the modern Internet.

What happened was, for quite some time after the third edition was finished, there were essentially no user visible changes such as syntax changes in the configuration for OpenBSD PF.

The code was definitely being worked on, developers fixed bugs, introduced optimizations such as network stack wide improvements in multicore support. But user-visible changes other than likely performance improvements did not appear, so I saw no urgent need to make updates to the book.

During the years following the late 2014 publication of third edition, I went on giving talks and tutorials, and at some point I welcomed input and help from my present co-presenters of the Network Management with the OpenBSD Packet Filter Toolset tutorials, Max Stucchi and Tom Smyth.

Over a few revisions, the tutorial sessions became ever more OpenBSD centered, possibly because we were all focusing more on that system than the others. And of course, over time we made tweaks to the material we present at the tutorials in response to our own real world experiences and feedback from attendees and others.

This went on for some years, with the still moderately popular conference sessions each yielding incremental changes to the material. Then, COVID-19 put all physical conference activities on hold for the years 2020 and 2021. EuroBSDCon 2022 in Vienna (originally planned as the 2020 conference), was our first post-lockdown presentation and a well attended one at that.

We went on to do more sessions at BSDCan 2023 and EuroBSDCon 2023. During the post-lockdown period, one question started popping up ever more frequently in email, social media (direct messages, even) and in connection with the sessions themselves,

Are you working on a fourth edition?

more often than not accompanied by

I'd love to get this in a FreeBSD version, can you do that too?

My answers would be roughly, "No tech book writer will ever reveal what their current project is until they have a specific publication date set", and "Sure, I will look into what I can do about that for sometime later"

On my way back from EuroBSDCon 2023 in Coimbra, where these questions had of course come up again, even from the quite small group of attendees at our session, I decided I that after eight years it might be worth at least looking into what, if anything beyond incrementing version numbers, would make sense to do to produce a new edition.

So I set out to assess. The book had seen some light touch updates for its second printing that were not in my pre-production .odt files, so I set out with the freshest .pdf and started making annotations. After a little while the volume of annotations had grown enough that I found it more useful to transfer those annotations to a normal text file. That file was becoming something like an outline of what a fourth edition would look like.

So testing my own 8 year old work against modern OpenBSD and FreeBSD, and poking around for PF material in general, I noticed several things.

Since the third edition was written, NetBSD, prominently featured in that edition, had developed their own NPF packet filter subsystem and deprecated their PF port. While DragonFly BSD still had PF in their tree, it looked like their version was seriously out of date (as far as I could tell equal to roughly OpenBSD 3.6, released in 2004).

So concentrating on the two free systems I was anyway in daily contact with -- OpenBSD and FreeBSD -- made sense.

My notes of things that needed to be done swelled over the next few weeks. The revision notes work became my main activity on evenings and weekends for a while, and by late November I sent off that file as an attachment to a mail message to Bill at No Starch that started with,

Dear Bill,
I think a fourth edition of The Book of PF might have a reason to exist soonish.

I went on to explain that while we had not had major announcements in the packet filtering space during the past few years, quite a few incremental and larger changes had indeed happened. A lot more had happened in user visible PF matters on the FreeBSD side than on the OpenBSD side, but incremental changes had happened there too.

And as you could reasonably expect, the world around us had changed enough that in addition to introducing some new features, existing examples and the way we present the issues to the reader needed a refresh in order to be relevant to anyone working in or starting out with modern TCP/IP networks.

It took some weeks before the yes, we're on board for a fourth edition message came back. It is entirely possible that making an important business pitch just before Thanksgiving weekend is not an optimal thing to do, timing-wise.

But when the go-ahead came, I asked Henning Brauer, who had been very much involved with technical editing for the previous versions, and Kristof Provost, who does the major PF things on the FreeBSD side, to be my tech reviewers. Both accepted immediately.

Over the next few months intense editing and revising followed -- yes, I do make mistakes, and Henning and Kristof proved to be very good at catching them.

Now we are very close to having the final result. The fourth edition of The Book of PF focuses on PF on modern versions of OpenBSD and FreeBSD, with only minor mention of other platforms. The ports to Apple systems and Oracle Solaris are mentioned, but I decided early on to focus on the free systems for all examples. The FreeBSD parts have received significantly more attention than in previous versions, to the extent that we jokingly referred to the fourth edition as the be nice to FreeBSD edition.

The editing process has taken longer than I had anticipated, but we are on track now to have copies in readers' hands some time in the second half of 2025. I hope I will be able to bring physical copies of the fourth edition to EuroBSDcon 2025 in Zagreb in September. There will be a revised and updated version of the Network Management with the OpenBSD Packet Filter Toolset session there, 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.

So summing up,

The fourth edition was written to bring the text into sync with the realities of the modern Internet, seen from the perspective of someone working with OpenBSD 7.8 or FreeBSD 14-STABLE.

The structure and chapter titles will be recognizable to readers of the previous edition, with the content updated to reflect the realities of the modern Internet.

If you have actually read this far, there is a good chance you might be interested in the book, the tutorial, or both. I welcome your comments and input.

---

If you found this piece to be useful, informative, annoying or would for some other reason like to contact me or comment, please do.

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

---