I still find SPF not worth integrating into my email server
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):
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:
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/