© 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](https://man.openbsd.org/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 with trackers but nicer formatting 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](https://man.openbsd.org/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](https://man.openbsd.org/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:

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:

1. From the Hail Mary Cloud data set
2. IMAP
3. 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):

4. ARTICLE (see the data)
5. 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)

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.

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.

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

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

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](https://man.openbsd.org/random.4) output, base64 encoded and stripped of certain characters that would possibly lead to [spamdb](https://man.openbsd.org/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](https://man.openbsd.org/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:

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](https://man.openbsd.org/random.4) I mentioned earlier, others came from using commands such as [rot13](https://man.openbsd.org/rot13) and [rev](https://man.openbsd.org/rev) on the things [grep](https://man.openbsd.org/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.

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](https://man.openbsd.org/grep) on the log files.

Later I set up to extract from the [spamd](https://man.openbsd.org/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](https://man.openbsd.org/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](https://man.openbsd.org/rot13) and [rev](https://man.openbsd.org/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](https://man.openbsd.org/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](https://man.openbsd.org/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)

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-02-01)

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.