The other day, I came across this article about using SPF (Sender Policy Framework) to avoid large delays using greylisting [1] (link via Lobsters [2]). I've experienced those delays from time to time since I run a greylist daemon [3] and this does seem like a neat idea. But I've already ironed out those large delays (it's been awhile since the last one) so I have very little incentive to implement this [4].
This did however get me to ask if I should integrate SPF (Sender Policy Framework) [5] with the greylist daemon [6].
Then I thought, didn't I already **do** this?
It turns out I did! Three years ago [7].
Well … okay then!
Have things changed over the past three years? I spent a few hours over the past few days getting the code up and running, so let's see—over the past month (December 10^th to January 10^th):
Table: Unique emails processed by the greylist daemon Emails accepted 2,515 Emails rejected 2,319 Total 4,834
Aside from the volume (which appears to be a bit less than 50% of what it was three years ago, but that could be due to the time of year), the ratio is similar—50% of the email is spam that is immedately filtered out.
The one major change though, is that back then, around 12½% only had SPF records, whereas today, it's about 12½% don't have SPF records. That's interesting. But the rest of the figures are again, similar to last time:
Table: Results of applying SPF policy against incoming email fail 93 IP (Internet Protocol) address was not allowed to send this email softfail 79 IP address should not be sending this email (used for testing) neutral 11 IP address has no policy pass 962 IP address is allowed to send this email
Those with a neutral SPF policy have gone down, and the failure rate is up a bit (4% vs. 1% back then) but the overall conclusion is the same—not worth it.
[1] https://poolp.org/posts/2018-01-08/spfwalk/