A Major Mail Provider Demonstrate They Likely Do Not Understand Mail At All

© 2026 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. It started out back when I was running a small business on the edge of tech, mainly dealing with software localization and documentation writing.

---

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

---

The company I had started with a few colleagues were in close cooperation with another business that worked in similar, but not primarily overlapping fields of interest.

Then during the early to mid 1990s, Internet and proper SMTP Internet email became available, and as one did at the time, we set up with a mail service, running at first on an early Red Hat Linux.

After a while we moved to a Debian setup, and over time, unlike most small businesses of the period, chose to not go for a Microsoft solution but rather moved to a setup based on the other free alternatives, with a combination of OpenBSD and FreeBSD for services.

When spam became annoying enough, we configured content filtering of various kinds, which lowered the noise level for a while. Later we discovered that our OpenBSD firewalls could also handle greylisting and tarpitting via spamd, and immediately saw that our mail feed became cleaner yet again.

Those of us who were in the server room when the greylisting was turned on, could not help noticing that the fan noise from the mail server just disappeared.

But one thing we did not get entirely rid of was bounce messages from other sites, directed to user names that had never existed in any of the domains we served. Clearly, one or more groups out there were sending 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:

1. 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 traffic from earlier, spamd answers one byte per second, finally presenting a Temporary local error, please retry later code and message. The host is greylisted. If the host returns with the same set of sender IP address, from and to addresses, it will be let through. Except in one circumstance which we will come back to very soon.

   If the message comes from a known bad sender IP address, spamd answers in a subset of SMTP at a rate of one byte per second, until the sending side gives up.

2. 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 of spamtraps, spamd adds the sending IP address to the set of likely valid senders, and passes the message on the real mail server.

3. The real mail server performs various checks on incoming mail, including whether the sending domain has valid SPF, DKIM and DMARC information and several kinds checks of message contents against known indicators of spam or malware.

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

5. If the to address does not match a valid recipient, the message is rejected with a bounce message back to the sending party.

6. 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.net
itsukiishibashimitaka@bsdly.net
kinoshitario0310@bsdly.net
kuromotoasuka_1007@bsdly.net
kyokomatsudakita@bsdly.net
motohashi_katsuyama@bsdly.net
namikiakari-funabashi@bsdly.net
namikidaisukeyamagata@bsdly.net
nomurajunichi_1958@bsdly.net
numanoenergy@bsdly.net
otaniasami@bsdly.net
rikoizawa2004@bsdly.net
sakakihifumi@bsdly.net
seoreina-1991@bsdly.net
shimamura_asahikawa@bsdly.net
sugimototaro.0321@bsdly.net
teshigawaraishikawa@bsdly.net
tokitakota.1968@bsdly.net
tsuboneyuji_mori@bsdly.net
ueki-miyagi633@bsdly.net
yamabenoboru@bsdly.net


The local parts or user names are not what you would expect to find in a business based in Norway.

But these 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 spam or phishing campaigns 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.net
fumiakihachiya0827@bsdly.net
hachiyaakira-stormchaser@bsdly.net
hanamurachihiro2000@bsdly.net
isaacclark.sarahclark@www.bsdly.net
izawanaoki0819@bsdly.net
junanzai0902@bsdly.net
kagawa.1965@bsdly.net
kashiwagi1967@bsdly.net
kawamurasoma1971@bsdly.net
kenmiyagawa1953@bsdly.net
kodama_1985@bsdly.net
kusunokiotsu@bsdly.net
liammartin.norakumar@lfja.org
machiasuka_1977@bsdly.net
masuda1955@bsdly.net
matsuoka-1976@bsdly.net
monmagenji654@bsdly.net
mutojunichi-noon@bsdly.net
nakaya-2017@bsdly.net
oscartanaka.zoeevans@lfja.org
rukanakagome1981@bsdly.net
ryuseiterasawa2021@bsdly.net
shinjiohno.futtsu@bsdly.net
tabatayusuke_0302@bsdly.net
tamuraryuji1995@bsdly.net
tsukuda2016@bsdly.net
usuda.ishikawa.star@bsdly.net
yoshidakatsuo@bsdly.net
yukitakahagi94770@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 overnight mail, I sent a message to a business contact of mine that uses a Google 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 messages now only land in the recipients' Spam 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.

---

Update 2026-01-09: One small batch of data might be of interest to my core readership. The output of a grep for "Unknown user" in the as-yet-unrotated mail server log is preserved in this file. My reading of this is that even the big names do not actually value their SPF/DMARC checks much at all.

---

Update 2026-01-10: A few hours after I had posted to the limited-distribution mailing lists for mail operators, and soon enough after I had published the original version of this article that it likely they did not read it yet, I was contacted by people who were plausibly claiming to be close to the actual developement and maintenance of the gmail codebase.

My impression, or at least the way I read what was in that communication, is that

• Gmail is a large code base that has been evolving over a long time

• The system is complicated enough and with enough factors (in the hundreds) involved that feeding the same message through the system several times is likely to produce different results each time

• The messages the system produces for external parties to see are unspecific at best and may in fact point to factors other than those that actually determined the pass/no pass decision

• The code has passed through many hands, and I at least get the impression that nobody currently there can honestly say they understand all aspects of the system

Despite all of this, they trust the system absolutely, claiming that it has a negligible false positive rate.

The last bit I at least think is a delusion that is sustained by the fact that they have made it pretty much impossible to file a problem report. It likely is easier for paying customers, but the only way in I have found is to post my gripes in public.

And yes, for every incident (there have been quite a few over the years) I have used side channels to contact my GOOG-using connections and ask them to file a problem report with as much details as possible. That seems to help, sometimes.

I had thought up a really snappy and harsh one-liner to characterize all of this, but I think I'll save that for another occasion.

---

A Major Mail Provider Demonstrate They Likely Do Not Understand Mail At All is © 2026 Peter N. M. Hansteen (published 2026-01-08)

---

Max Stucchi and I will be giving a PF tutorial at AsiaBSDC0n 2026, 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.

---

Is SPF Simply Too Hard For Application Developers?

The Sender Policy Framework (SPF) is unloved by some, because it conflicts with some long-established SMTP email use cases. But is it also just too hard to understand and to use correctly for application developers?

Here is a story involving a web-based contact form that indicates that this may be the case.

A wise man once noted that only two things in life are inevitable: death and taxes.

Just how taxes and interactions with the tax authorities are handled vary widely from jurisdiction to jurisdiction, but in Norway, where I live, the default mode of contact with the tax authorities for most of us is via web forms protected by sometimes cumbersome authentication procedures and the occasional alert via SMS text message to your phone.

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

And we're used to that the things just work with only occasional and very minor technical embarrassments for the people who operate the thing.

Then in August 2016, I tried to report a bug via the contact form at Altinn.no, the main tax authorities web site.

The report in itself was fairly trivial: The SMS alert I had just received about an invoice for taxes due contained one date, which turned out to be my birth date rather than the invoice due date. Not a major issue, but potentially confusing to the recipient until you actually log in and download the invoice as PDF and read the actual due date and other specifics.

The next time I checked my mail at bsdly.net, I found this bounce.

The meat of the message is

support@altinn.no
    SMTP error from remote mail server after RCPT TO::
    host mx.isp.as2116.net [193.75.104.7]: 550 5.7.23 SPF validation failed   

which means that somebody, somewhere tried to send a message to support@altinn.no, but the message could not be delivered because the sending machine did not match the published SPF data for the sender domain.

SPF expands to "Sender Policy Framework", which is one of the early and still valid ways for a domain to publish which hosts are supposed to be sending mail on the domain's behalf.

There is no requirement to refuse delivery of mail from a host that is not in a domain's SPF record, and emphatically so when no such record exists. On the other hand, when a domain does publish SPF data, rejecting mail from hosts that are not in the set published is a valid and accepted action.

What happened is actually quite clear even from the part quoted above: the host mx.isp.as2116.net [193.75.104.7] tried to deliver mail on my behalf (I received the bounce, remember), and since I have no agreement for mail delivery with the owners and operators of that host, it is not in bsdly.net's SPF record either, and the delivery fails.

The bounce message contained one Received: header which tells part of the story, and after decoding the MIME-encoded part it becomes clear that it contains my bug report with some slightly odd markup.

So it's clear that what produced the bounce was that the contact form had tried to deliver mail using the address I had given the contact form.

I can hear your groans all the way from there to here.

My original bug report had not been delivered, but I thought perhaps I could help them with the other problem, so I sent off a new message to the addresses that were given as contacts in the altinn.no domain's whois info, taking care to send it from a machine that was properly authorized to send mail for my domain.

The full text of the message is available here, in Norwegian. The message includes the bounce with a short introduction that said essentially "this is the result of trying to submit a bug report via your web contact form. This is clearly an SPF problem, please look into that".

Then that message bounced, too.

The exact reason is likely buried in the configuration files for altinn.no's MX, but it could be that it has some reservations against accepting mail from what it sees as a subdomain that doesn't have an MX record of its own.

Anyway, by then I had spent far too much time on this rather trivial matter while I was supposed to be doing other things, so I quickly wrote up a summary and sent it off to the same contact addresses, this time from my gmail.com account, with the various accumulated data as attachments.

Then, as often happens when dealing with the authorities, nothing happened. For quite a while.

It was only on October 18, 2016 that my gmail.com account received a reply from the support address, which quoted my last message in full, and added their resolution text saying:

"Løsning:
Det kan se ut som du har Sender Policy Framework (SPF) aktivert på din mailserver, Det er en kjent svakhet ved vårt kontaktskjema at mailservere med SPF ikke støttes."

Translation:

"Solution:
It looks like you have Sender Policy Framework (SPF) enabled on your mailserver, It is a known weakness of our contact form that mailervers with SPF are not supported."

Once again, I can hear and fully sympathize with your groans.

This is as perfectly wrong as can be, in fact the exact opposite of right.

The obvious answer should be, as you will agree if you're still reading: The form's developer should place the user's email address in the Reply-To: field, and send the message as its own, valid local user. That would solve the problem.

So I put it to you: Is SPF, the Sender Policy Framework, simply too hard for application developers to understand?

Yes, I'm well aware that SPF also breaks traditional forwarding of the type generally used by mailing lists and a few other use cases. Just how afraid should we be when those same developers come to do battle with the followup specifications such as DKIM and (shudder) the full DMARC specification?

I anticipate your feedback in comments, or if you have things you really want me to only paraphrase in public, email.

---

Update 2016-12-02: While looking for something else entirely, I stumbled across the DMARC FAQ, where the next to final entry describes the exact problem described in this column. Developers should perhaps learn to read FAQs.

To wit,

Why are messages I send on behalf of visitors to my website being blocked?

This depends on how you are sending these messages. If you are simply taking the website visitor’s email address and inserting it into the “From:” header of the message, and sending that message from your own servers, then you are impersonating the domain in their email address – in a way that is indistinguishable from spammers. These practices may have worked previously – in many cases for decades – because before spam became a literally overwhelming problem, nobody checked. The most successful initial mechanisms to combat such spam were IP address-based blocklists, and so your site may have been allowed to continue because it did not appear on such a list.

For the past decade, however email authentication has been introduced as a filtering mechanism, and is increasingly being used to detect and block such messages.As a best practice, you should instead be using a domain you control in the address of the From: header, and use mechanisms like SPF, DKIM, and DMARC to show that this message is authorized to use your domain. In the example below, the site visitor’s name is shown in the descriptive part of the From: header, and the Reply-To: header is set to the website visitor’s address, but the actual address used in the From: header clearly indicates that your website is the origin of the message.

From: "John Doe via the Example Website" <service@website.example.com>
Reply-To: "John Doe" <john@firstmailboxprovider.com>
To: "Bob Smith" <bob@secondmailboxprovider.com>
Subject: "An article I thought you would find interesting"

Taken from the DMARC.ORG FAQ: 4.23 Why are messages I send on behalf of visitors to my website being blocked? as of December 2. 2016.