Wednesday, January 10, 2018
I still find SPF not worth integrating into my email server
The other day, I came across this article about using SPF to avoid large delays using greylisting (link via Lobsters). I've experienced those delays from time to time since I run a greylist daemon 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.
This did however get me to ask if I should integrate SPF with the greylist daemon.
Then I thought, didn't I already do this?
It turns out I did! Three years ago.
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 10th to January 10th):
| 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:
| fail | 93 | IP 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.
![[The future's so bright, I gotta wear shades]](https://www.conman.org/people/spc/about/2023/1023.t.jpg "The future's so bright, I gotta wear shades")