© 2025 Peter N. M. Hansteen So it happened again. A major mail provider proved that they do not, in fact, understand how modern email works.I've been running mail services for longer than I care to remember. Itstarted out back when I was running a small business on the edge oftech, mainly dealing with software localization and documentationwriting. Note: This piece is also available without trackers but classic formatting only here.The company I had started with a few colleagues were in closecooperation with another business that worked in similar, but notprimarily overlapping fields of interest.Then during the early to mid 1990s, Internet andproper SMTPInternet email became available, and as one did at the time, we set upwith a mail service, running at first on anearly Red Hat Linux.After a while we moved toa Debian setup, and over time,unlike most small businesses of the period, chose to not go fora Microsoft solution but rather moved to a setup based on theother free alternatives, with a combinationof OpenBSDand FreeBSD forservices.When spam became annoying enough, we configured content filtering ofvarious kinds, which lowered the noise level for a while. Later wediscovered that our OpenBSD firewalls could alsohandle greylistingand tarpittingvia spamd,and immediately saw that our mail feed became cleaner yet again.Those of us who were in the server room when the greylisting wasturned on, could not help noticing that the fan noise from the mailserver just disappeared.But one thing we did not get entirely rid of was bounce messages fromother sites, directed to user names that had never existed in any ofthe domains we served. Clearly, one or more groups out there weresending messages with faked addresses in our domains. So I was very happy when I found that in the OpenBSD 3.3 release, spamd offered a new feature called greytrapping, which meant we could actually put those fake addresses to good use. From that point on, a high level view of mail delivery to our systems work like this: When a message arrives, spamd checks whether we have received mail from that host in recent times. Mail from known sending hosts is sent on to the mail server. If the message comes from a host we have not seen SMTP trafficfromearlier, spamdanswers one byte per second, finally presentinga Temporary local error, please retry later code andmessage. The hostis greylisted. Ifthe host returns with the same set of sender IPaddress, from and to addresses, itwill be let through. Except in one circumstance which we willcome back to very soon. If the message comes from a known bad sender IPaddress, spamdanswers in a subset of SMTP at a rate of one byte per second,until the sending side gives up. When a message comes from a greylisted host, spamd checks whether the to address is in the list of spamtraps. If if the message matches this criterion, the sending IP address is added to teh the list of hosts with a TRAPPED status and will receive the one byte per second treatment until the sending party gives up. Addresses that enter the spamd-greytrap set stay there until 24 hours after the time of last contact. If the to address is not in the list ofspamtraps, spamd adds the sending IP address to the set oflikely valid senders, and passes the message on the real mailserver. The real mail server performs various checks on incoming mail, including whether the sending domain has valid SPF and DMARC information and several kinds checks of message contents agains known indicators of spam or malware. If the message passes all those validity and content checks, the mail server check whether the to address matches a valid recipient in the domains we handle. If the to address does not match a valid recipient, the message is rejected with a bounce message back to the sending party. If the to address does match a valid recipient, the message is delivered according to the configuration that is in place for that recipient. The main difference between this setup and any mail server you will have heard about, is that we have a list of spamtraps. The source for spamtraps was originally the invalid addresses that turned up in our mail server logs. Later, with greylisting in place, the obvious selection criterion was checking the greylist for addresses that did not match any local recipient or an existing spamtrap. Over time the number and kinds of sources expanded a bit. You can read all you want about that and more in the retrospective article Eighteen Years of Greytrapping - Is the Weirdness Finally Paying Off? I have an hourly cron job that runs a script that exports the list of trapped IP addresses for use elsewhere and produces a report of various useful items, including a list of possible new spamtraps, extracted from the greylist. The overnight batch on January 8th, 2026 looked like this: fuchigamikamogawa522@bsdly.netitsukiishibashimitaka@bsdly.netkinoshitario0310@bsdly.netkuromotoasuka_1007@bsdly.netkyokomatsudakita@bsdly.netmotohashi_katsuyama@bsdly.netnamikiakari-funabashi@bsdly.netnamikidaisukeyamagata@bsdly.netnomurajunichi_1958@bsdly.netnumanoenergy@bsdly.netotaniasami@bsdly.netrikoizawa2004@bsdly.netsakakihifumi@bsdly.netseoreina-1991@bsdly.netshimamura_asahikawa@bsdly.netsugimototaro.0321@bsdly.netteshigawaraishikawa@bsdly.nettokitakota.1968@bsdly.nettsuboneyuji_mori@bsdly.netueki-miyagi633@bsdly.netyamabenoboru@bsdly.net The local parts or user names are not what you would expect to find in a business based in Norway. But they Japanese-sounding names are quite typical of the backscatter we have been seeing here during the last two or three years. Most likely somebody is running a spam or phishing campaign aimed at Japanese users. The bounce messages do not ever reach an inbox, but they do turn up in the greylist dump in the hourly message. There, the in the fourth column reveals that the messages were indeed bounce messages. The afternoon batch looked similar: aoki-1990600@bsdly.netfumiakihachiya0827@bsdly.nethachiyaakira-stormchaser@bsdly.nethanamurachihiro2000@bsdly.netisaacclark.sarahclark@www.bsdly.netizawanaoki0819@bsdly.netjunanzai0902@bsdly.netkagawa.1965@bsdly.netkashiwagi1967@bsdly.netkawamurasoma1971@bsdly.netkenmiyagawa1953@bsdly.netkodama_1985@bsdly.netkusunokiotsu@bsdly.netliammartin.norakumar@lfja.orgmachiasuka_1977@bsdly.netmasuda1955@bsdly.netmatsuoka-1976@bsdly.netmonmagenji654@bsdly.netmutojunichi-noon@bsdly.netnakaya-2017@bsdly.netoscartanaka.zoeevans@lfja.orgrukanakagome1981@bsdly.netryuseiterasawa2021@bsdly.netshinjiohno.futtsu@bsdly.nettabatayusuke_0302@bsdly.nettamuraryuji1995@bsdly.nettsukuda2016@bsdly.netusuda.ishikawa.star@bsdly.netyoshidakatsuo@bsdly.netyukitakahagi94770@bsdly.net The addresses in both of these batches were added to our spamtraps, affectionately known as our imaginary friends, along with a number of synthetic entries as described in the longer article Eighteen Years of Greytrapping - Is the Weirdness Finally Paying Off?. But that day, after processing new spamtraps and a bit of overnightmail, I sent a message to a business contact of mine that uses aGoogle as their mail service provider. That produced a bounce message,some of which is quoted in this graphic: I had put my own gmail.com address on Cc:, in part due to various earlier episodes with that provider. The diagnostic was the same for the other recipients. This means that after several years of mostly managing to deliver messages sent from our systems to their intended recipients in Google managed domains (at random times deciding to put mail from here in their users' Spam folders), somebody decided it was time to disregard our domains' published SPF and DMARC information. Their "very low reputation of the sending domain" is is likely down to a very poor understanding of how modern mail delivery works. More likely than not, the volume of messages sent with faked sender addresses claiming to be from our domains and a source IP address in the great elsewhere is vastly larger than the actually valid messages sent from valid users, all of which will come from the hosts listed in our published records. The existence of spamtraps should not be a surprise either, after all we have been doing greytrapping for more than eighteen years. I would posit that this is a mail services provider that has demonstrated that they do not, in fact, understand SMTP mail at all. Fortunately, posting the data and a description of the incident to a mailing list for mail administrators indicates that persons who work for that operator read that list, since the problem lessened a bit a few hours later. My messagess now only land in the recipients' Spame folders. I would like to invite a debate about incidents of this type. The big operators can be quite nasty to smaller players, as we can see from this episode and the earlier one you can find by following links in this article. What are the sensible standards of behavior (aka netizenship) to expect from mail service providers? Should, for example, we consider making the large operators (or smaller ones, for that matter) liable for damages for mishandling their service offerings like this? Followup in comments to this article (where possible) or to the social media post that lead you to find this article. Max Stucchi and I will be giving a PF tutorial at AsiaBSDC0n 2016, and I welcome your questions now that I'm revising the material for that session. See this blog post for some ideas. For more information about the BSD conferences, see What is BSD? Come to a conference to find out! (also tracked). For a broader overview and retrospective of mail and greytrapping, you may be interested in reading Eighteen Years of Greytrapping - Is the Weirdness Finally Paying Off?, which links to this piece and a number of other related resources. You might also be interested in reading selected pieces via That Grumpy BSD Guy: A Short Reading List (also here). Separately, pre-orders of The Book of PF, 4th edition are now open. For a little background, see the blog post Yes, The Book of PF, 4th Edition Is Coming Soon (also here). The latest information I have is that physical copies should be ready to ship by the end of January 2026.