Sunday, December 28, 2025

Why 451 is Good for You - Greylisting Perspectives From the Early Noughties

© 2025 Peter N. M. Hansteen

A software vendor was using SMTP spamware to send license keys customers had paid thousands for. A measured rant was in order, and turned out to be quite enlightening.

While looking thrugh directories of old material, I stumbled upon what was most likely the main part of a complaint sent to a software vendor for failing to deliver a license key file the company I worked for then had paid some thousands of dollars for.

The file as I found it was dated August 2010, but was likely a preserved copy of a draft that was written some time before the first edition of The Book of PF (now in its fourth edition) was published, in response to the non-delivery incident. A quick investigation had me conclude from my spamd logs that their side did not play well with greylisting.


Note: This piece is also available without trackers but classic formatting only here.
I have revisited the handling sites that do not play well with greylisting theme a number of times, such as the 2018 piece Goodness, Enumerated by Robots. Or, Handling Those Who Do Not Play Well With Greylisting (also here).

But I found these early notes interesting enough that I include them here, with only minor redactions to protect the (relatively) innocent:

SWCrafters' reaction to finding out that their messages do not get through, essentially blaming "inaccurate spam filtering" was not unexpected, but I will take the opportunity to explain a few things about how Internet email works and how this makes their position at odds with reality.

Even though Internet services are offered with no guarantees, usually described as 'best effort' services, a significant amount of effort has been put into making essential services such as SMTP email transmission fault tolerant, making the 'best effort' one with as close as does not matter to having a perfect record for delivering messages.

The EXECUTIVE SUMMARY of this message is that the matter which trips up the delivery of SWCrafters' license-carrying emails is the fact that their email sending software's best effort at delivery falls significantly short of what current Internet standards require.

The current standard for Internet email transmission is defined in RFC2821, which in section 4.5.4.1, "Sending Strategy", states

"In a typical system, the program that composes a message has some method for requesting immediate attention for a new piece of outgoing mail, while mail that cannot be transmitted immediately MUST be queued and periodically retried by the sender."
and
"The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the SMTP client can determine the reason for non-delivery."
Contrast this with the application which sends the SWCrafters license information messages, which according to the data I have avaliable opens two SMTP sessions within a second of each other (the time resolution I have in my logs at the moment), apparently discarding the message without delivery afterwards.

RFC2821 goes on to state that

"Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days."
After all, delivering email is a collaborative, best effort thing, and he RFC states clearly that if the site you are trying to send mail to reports it can't receive anything at the moment, it is your DUTY (a MUST requirement) to try again later, after an interval which is long enough that your unfortunate communication partner has had a chance to clear up whatever was the problem.

A sending strategy which relies on every receiver to be receptive at all times, discarding undelivered messages after only one unsuccessful attempt, possibly makes sense if the data you are sending is unimportant or if your intended targets are unlikely read or even want to receive the messages you send.

If on the other hand the data you are sending matter to either you or the intended recipient, it is in everybody's interest that you use the fault tolerance features which a compliant SMTP mail system offers.

To put this in context, you need to remember that the SWCrafters license messages are the result of some SWCrafters customer ordering at least a thousand dollars' worth or software licenses, with no real upper limit on the dollar value of a single message. The system used to send these messages apparently does not understand SMTP status messages, discarding undelivered messages without a trace. Essentially, the system you are using treats the data your customers expect to receive in exchange for thousands of dollars paid as discardable.

The "greylisting" technique which is in use at justgottahave.faith and other sites means that our systems expect any SMTP sender to understand SMTP status codes and to respect "451 temporary error please try again later" messages. The hows and whys are detailed at https://www.greylisting.org/, with a tutorial which contains a 'close enough' description of how it's done at datadok to be found at https://home.nuug.no/~peter/pf/, with the particulars starting at https://home.nuug.no/~peter/pf/en/spamd.html.

We do content filtering as well, but this particular application never managed to get its data sent far enough to encounter content filtering until its IP address got whitelisted (listed as 'known good', or if you will, not having to conform to normal criteria).

Greylisting works extremely well, and since it is both standards compliant (essentially insisting on compliance) and simple to implement you should expect it to be deployed at the next site you are trying to send email to.

If I remember correctly, the other side found a way to send the missing license codes with something that did handle SMTP status codes correctly a short time after the mail that included some version of these notes was sent.

I had originally intended to make the URLs in the text here clickable, but changed my mind when I discovered that the current operators of greylisting.org have decided that a large language model (the current iteration of what passes for artificial intelligence needed to be included in the processing. That will perhaps serve as a sign that the world does move on, if not necessarily in useful directions at all times.

If you want to explore the ins and outs of greylisting and the related phenomenon greytrapping, my recent piece Eighteen Years of Greytrapping - Is the Weirdness Finally Paying Off? (also here) is a way to start. For the greylisting part, the notes above capture the main points.


Why 451 is Good for You - Greylisting Perspectives From the Early Noughties is © 2025 Peter N. M. Hansteen (published 2025-12-28)
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.


No comments:

Post a Comment

Note: Comments are moderated. On-topic messages will be liberated from the holding queue at semi-random (hopefully short) intervals.

I invite comment on all aspects of the material I publish and I read all submitted comments. I occasionally respond in comments, but please do not assume that your comment will compel me to produce a public or immediate response.

Please note that comments consisting of only a single word or only a URL with no indication why that link is useful in the context will be immediately recycled so those poor electrons get another shot at a meaningful existence.

If your suggestions are useful enough to make me write on a specific topic, I will do my best to give credit where credit is due.