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.
You know, the ability to comment on-the-fly configuration changes in long running daemons is probably a good idea
And speaking of the greylist daemon, I can filter by IP address:
[spc]brevard:~>gld-mcp show iplist
30905 GREYLIST 0.0.0.0 0.0.0.0
115 REJECT 61.175.186.125 255.255.255.255
0 ACCEPT 64.12.0.0 255.255.0.0
0 ACCEPT 64.233.160.0 255.255.224.0
0 ACCEPT 66.94.224.0 255.255.224.0
0 ACCEPT 66.102.0.0 255.255.240.0
33 ACCEPT 66.163.160.0 255.255.224.0
0 ACCEPT 66.218.64.0 255.255.224.0
81 ACCEPT 66.220.144.128 255.255.255.128
0 ACCEPT 66.249.80.0 255.255.240.0
0 ACCEPT 66.249.64.0 255.255.224.0
0 ACCEPT 66.252.224.0 255.255.252.0
0 ACCEPT 69.63.184.0 255.255.255.128
0 ACCEPT 69.63.176.0 255.255.240.0
0 ACCEPT 69.147.64.0 255.255.192.0
4 ACCEPT 70.34.16.0 255.255.240.0
0 ACCEPT 72.14.192.0 255.255.192.0
16 ACCEPT 74.125.0.0 255.255.0.0
0 ACCEPT 127.0.0.1 255.255.255.255
1207 ACCEPT 140.211.11.3 255.255.255.255
0 ACCEPT 149.174.0.0 255.255.0.0
12 REJECT 172.128.0.0 255.128.0.0
7 GREYLIST 173.232.0.0 255.255.0.0
115 GREYLIST 173.0.0.0 255.0.0.0
0 ACCEPT 192.168.0.0 255.255.0.0
0 ACCEPT 204.127.217.0 255.255.255.0
0 ACCEPT 204.127.0.0 255.255.0.0
0 ACCEPT 205.152.58.0 255.255.254.0
0 ACCEPT 205.188.156.0 255.255.254.0
0 ACCEPT 205.188.0.0 255.255.0.0
0 REJECT 206.214.64.0 255.255.224.0
0 ACCEPT 207.115.11.0 255.255.255.192
0 ACCEPT 207.115.0.0 255.255.192.0
0 ACCEPT 207.171.188.0 255.255.255.0
116 ACCEPT 209.85.128.0 255.255.128.0
0 ACCEPT 209.131.32.0 255.255.224.0
3 ACCEPT 216.39.48.0 255.255.240.0
0 ACCEPT 216.239.32.0 255.255.224.0
[spc]brevard:~>
But there's a question I can't answer—why?
Why did I accept 69.63.184.0/19?
Or 216.39.48.0/20?
Heck,
I can't even answer when!
What I wish I had done back when I wrote this was allow comments for this filter table.
I mean,
it's pretty obvious with some of the other filters,
such as the to-domain list:
[spc]brevard:~>gld-mcp show to-domain
0 REJECT area51.conman.org
75 REJECT linus.area51.conman.org
30530 GREYLIST DEFAULT
[spc]brevard:~>
The machine linus.area51.conman.org has been decommissioned for over a decade,
and yet some spammers somewhere are still attempting to deliver email to it
(although it may help if I were to remove the MX and A
DNS records for it—hmm …) even after all these years
(75 attempts have been attempted since September 6th, 2017
when for whatever reason,
the greylist daemon was restarted).
It's obvious why I added the line.
But the IP addresses? No idea. The ability to add comments for ad-hoc, on-the-fly updates for long running daemons is something to keep in mind. I just wish I had thought of that sooner.
