I will belabor this a little, because it is at the core of my frustrations with the email filtering industry.
SPF would work if all SPF records were exactly correct, and if no legitimate senders ever infringed on someone else's SPF rule. Both are false.
If a vendor is developing a tool that uses both address and IP to check an SPF record, it would seem obvious that the system also needs a way to bypass SPF using an address and an IP. Wow! A 2-attribute rule needs a 2-attribute exception!
A little time spent looking at mail streams will add complexity. The exception is not really for address and IP, it needs to be an exception for sender address and server farm. One such farm is outlook.com, where the list of all IPs is large, unknown, and unknowable. So the system needs the ability to define exceptions using address and server host name for complex server farms, as well as address and IP for simple situations.
But host names can be fraudulent, so we really need to know that the host name can be forward-resolved to the Source IP address before it is completely safe to use the host name to reduce filtering.
But every mail message has two potential host names, the HELO name and the ReverseDNS name, some will be verifiable and some will not. In my dataset, as a percent of messages, I have 7% unconfirmed, 16% confirmed on HELO name only, 15% confirmed on ReverseDNS name only, and 62% confirmed on both names.
All too many email filtering products, including SmarterMail's custom rule feature, can only filter on a single attribute. So there is no good way to override an SPF problem. I can whitelist the IP or whitelist the Sender or whitelist the server dns names (by filtering on header=Received). Trying to build a multi-attribute rule from a series of scores will quickly prove difficult to sustain,.
But SmarterMail is not primarily an email filtering product, so its limitations are not surprising. What shocks is the number of specialized email filtering products that cannot do multiple-attribute rules for problems like SPF exceptions. In many case, there is also no granularity to the exception process -- if you want to override SPF, you agree to accept everything that is whitelisted short of obvious malware attachments.
I categorize incoming mail like this:
- Business-essential messages that must be received.
- Acceptable but non-essential messages, mostly advertising.
- Nuisance messages: Unwanted but harmless, mostly advertising.
- Hostile/Malicious messages.
Spam filtering has as it's goal to block 100% of group 4 and as much as possible from group 3. It can have false positives that extend into group 2, but the system must have the ability to implement exceptions to pass everything in group 1.
The point of Mr. Kaufmans' question was that his messages from group 1 are being blocked, and the mail system administrator does not have an adequate tool for creating an exception to allow the message. Given the limitations of his toolkit, the appropriate response is to disable SPF filtering. Since they are unwilling to do so, Mr Kaufman should find a new mail system vendor.
Besides, if the mail system vendor is only using SmarterMail for spam filtering, the filtering is probably inadequate anyway.