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.
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):
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.